冒号和他的学生们（连载27）——接口服务 - 编程入门网

众人一阵哄笑，叹号面红耳赤，仿佛真的犯了错似的。

“刚才我们说过，超市开放货舱后门属管理不善，而客户钻进去取货属不守规矩。类似地，行人横穿马路的问题也有两方面的因素。”冒号重提前例，“说回User类，其设计者肯定不希望客户通过此种方式来修改birthday，否则也不会提供setBirthday的接口。”

逗号颇为不服：“可是setBirthday中除了简单的赋值什么也没干哪！”

“哈哈，又忍不住偷看源代码了吧！”冒号逮了个正着，“你怎么能保证User类的作者哪天不心血来潮，在setBirthday中写一些不同寻常的代码？不要轻视任何一个接口，哪怕它暂时只有一个空语句的实现。事实上，许多空接口就是为将来的功能扩展预留的，随时可能被充实，或者被子类覆盖。”

逗号心里话：得，又掉沟里了！

冒号和他的学生们（连载27）——接口服务(3)

冒号续道：“第二个例子涉及Java中的Swing。一般说来，如果一个组件的可视化性质如位置、尺寸等发生改变，都需要重新布局（layout ）。凡是Swing组件（component ）都要调用revalidate 方法。绝大多数情况下，setText、setFont、setIcon等方法的实现中会自动调用revalidate，但仍有少数例外。规范文档中又语焉不详，令人困惑。为保证不受源码变动的影响，同时免除记忆之困，最好在一个组件所有与布局相关的变化完毕后，专门调用一次revalidate。以轻微的性能代价换来长治久安，无疑是正确的。相反，依赖源代码而非规范文档编程，显然是危险的。如果说第一个例子直接破坏了封装，有可能马上被察觉，该例则隐蔽得多——只要在所依赖的源代码不变，一切都正常。然而一旦有变，后果难以预料。”

引号不免有些感慨：“一般人熟悉JDK的API文档多过熟悉源码，尚且可能犯依赖源码编程的错误。如果重用同一开发组的代码，甚至是本人的代码，对源码非常熟悉，偏偏文档还匮乏，这种错误更是在所难免。”

“意识到这一点就是很大的进步啊。”冒号欣慰道，“再举一例。有时在使用一个类时，你很想重用其中一个protected方法，但当前所在的客户类既不是其子类，所在的package也不同。怎么办？”

句号承认：“以前的确碰到这样的问题，第一感觉是恨那作者太小气：为什么不干脆将其设为public与众共享？转念一想，大不了写个继承的子类，别的事不做，专门把那些protected方法转化为public。”

“是不是这样？”冒号在黑板上飞快地写下——

class Reserved { 　　 protected void f(){/**/} 　　 protected int g(){/**/} 　　 … } class Open extends Reserved { 　　 public void f(){super.f();} 　　 public int g(){return super.g();} 　　 … }

见句号点头，冒号问：“你不觉得有何不妥吗？”

“很俗很暴力。”句号的自评令众人喷饭。

冒号分析道：“你既然那么希望调用某个protected方法，说明它一定不平凡，但为何作者遮遮掩掩、不愿公开呢？假若他的设计是合理的，那么只有一个解释：它是为内部或子类服务的，本就不打算对外开放。你所需要的服务要么是设计者刻意回避的，要么接口另有所在，说不定还恰好调用了你所需要的方法呢！”

一束光芒从众人脑际划过。

冒号又补充道：“不轻易公开他人的protected成员还有一个理由。正因为protected的接口比public使用的范围狭窄得多，接口变动的可能性往往也更大，客户应该慎用。总之，道法自然，不自然的另一面通常是不正确，请注重培养这种编程嗅觉。”

逗号使劲吸了吸鼻子。

冒号遂作结语：&ldquo

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!