文章目录

感谢IT牛人博客聚合上还能找到我之前博客的一些内容,因为之前主机没续费等各种原因,也懒得翻之前的备份文档了,就把那上面的文章直接拷过来整理一下好了,只搬迁一些还有意义的内容好了,其他的就让它随风而去吧。

记得刚接触面向对象的程序设计时,就知道了这样一个原则,就是类的成员最小公开化。由于当时做的基本是特定开发,再加上各种教程的“误导”,所以想当然的认为能private的绝不friendly,能friendly的绝不protected。当然,其实protected都很少会用,大部分时候都是public或者是private的。然而最近在做写终搜新版本以及看一些经典开源代码时,发现其实很多时候都是protected或者friendly的,并不是清一色的private,这不得不让我思考,到底什么是最小公开化原则。

首先先来复习一下Java中四种可见度,首先private是私有的,只有这个类的成员可以访问,可见度最小;可见度第二小的是friendly,只对同一包内的类及其成员可见;第三小的是protected,对该类的派生类及同一包内的类可见;public顾名思义。之所以会有可见度,是因为要避免这些方法或者成员在其作用域外被误用,导致程序出现不可预知的行为。

按照大多数POJO的例子,其域成员都是private的,然后通过getter和setter去读写其值。所以以前写的绝大多数类都是私有成员,但放在产品的角度来考虑,这样真的合适么?当你觉得某一个非final类的行为并不符合你的需求时,你的第一想法是什么?继承这个类,然后用派生类代替该类,重写不符合预期的想法。现在问题来了,既然很多成员都是私有的,那么在你的派生类中就不能直接利用这些成员了,要么自己定义成员,要么用臃肿的setter和getter吧。为么会有继承?很大程度上是为了实现代码的高度复用,但是现在你的代码的使用者不得不继承你的类,然后重写这些需要用到的成员,并一边骂着:“靠,用个protected会死啊!”

没错,最小公开化不代表完全私有化,在确保其不在作用域外被误用的情况下,还要尽可能的“开放”以为你的后人提供方便。那么到底什么情况下适合用private呢?如果你确信这个类永远也不可能被继承重写,那么你大可以给类加上个final,然后放心大胆的用private去标注那些需要隐藏的实现。另外一种情况,如果你的属性或者方法只是某个方法特殊的中间调用产物,而你有确信这段代码不会被其他人复用,那么你可以放心的用private。如果你觉得你的类可能会被继承重写,那么最后给每一个要隐藏的成员标注protected,这样既为你的代码的使用者提供方便,又起到了保护代码的作用。

但问题并不是这么简单,问题就在于Java中protected的语义,按照我们传统观念来说——也就是目前C#, Scala等语言中的protected那样,protected修饰的成员应该只对该类及其子类的成员可见,但很遗憾,不知道Java最初的设计者出于哪方面考虑,protected也可以被同包的类访问,也许是因为最初的类库一个包中的类经常共用一些成员,但是又与其他包的业务无关吧。总之,这是游戏规则的一个失误。你也许会说,大量使用protected也许会不小心被同一个包的类误用,但是,必须说的是,这个做法本身是一个错误的用例。而且,别忘了,Java提供了反射,这个足以改变游戏规则的武器,所以没有什么代码是真正安全的,除非你自己足够小心。

所以,尽量多用protected吧,当你有一天需要继承先前类,并且只重写一两个非公开方法时,你会感觉到非常爽的。

文章目录