使可访问性最小化

模块设计是否良好，有个重要的因素在于，相对外部模块是否隐藏内部数据以及实现细节。
设计良好的模块会隐藏实现细节，并将API与其实现隔离开来。
模块之间通过API进行通信，对于内部工作情况互不可见。
即，封装（encapsulation）——软件设计的基本原则之一。

为什么要封装？
通过封装可以有效地接触各个模块之间的耦合关系，使这些模块可以独立地开发、测试、优化、使用、理解和修改。
即：

可以增加开发效率，模块可以并行开发。

封装可以减轻维护的负担，可以更有效的进行优化，且不会影响其他模块的正确性。

提高了软件的可重用性，模块在其他环境中也可以被使用。

(PS:回想我自己以前用php写网站时根本没有这些概念也不影响开发工作。当时觉得没什么，因为是我一个人写的，再加上后来也没有再扩展，于是没有了种种体会。)

可以通过访问控制保证封装。
一个实体的可访问性是通过实体声明所在的位置和访问修饰符共同决定的。
建议尽可能地使每个类或者成员不被外界访问。

对于顶层的类和接口只有两种访问级别：包级私有和公有。
更小的可访问性代表更小的兼容性，在以后发行的版本中可以放心对其进行修改。
如果是公有的，则需要一直考虑客户的行为。(PS：如果一个顶层类只是在某一个类的内部被用到，则可以声明为私有静态内部类。)
比如这样一个类，这样做在以后的版本中便无法改变表示方式，而且无法加入任何约束：

class Point { public double x; public double y; }

于是正如很多人的习惯那样，对于公有类用公有的访问方法替代公有field以保证数据在类内部的灵活性： class Point { private double x; private double y;

public Point(double x, double y) { this.x = x; this.y = y; } public double getX() { return x; } public double getY() { return y; } public void setX(double x) { this.x = x; } public void setY(double y) { this.y = y; } }

(PS：当然，有些常见的类并没有遵守这一规则比如Java.awt.Point、java.awt.Dimension。
但原作者也明确指出这些类不值得效仿。)

如果一个field只能是公有的，且允许将其声明为final，则危害能少一些。
我们仍然可以通过公有的访问方法访问该field。
但不能用公有的setter，而是通过构造器加入约束：

public final class Time { private static final int HOURS_PER_DAY = 24; private static final int MINUTES_PER_HOUR = 60; public final int hour; public final int minute; public Time(int hour, int minute) { if (hour < 0 || hour >= HOURS_PER_DAY) throw new IllegalArgumentException("Hour: " + hour); if (minute < 0 || minute >= MINUTES_PER_HOUR) throw new IllegalArgumentException("Min: " + minute); this.hour = hour; this.minute = minute; } // Remainder omitted }

对于成员(field,method,嵌套类,嵌套接口)有4种访问级别：

private

package-private（default）

protected

public

当设计了类的公有API后，我们将所有成员都变成私有。
然后发现同一个包内的另一个类也需要访问这个成员，于是便修改访问级别。如果这种事情经常发生则应该检查设计是否合理。
虽然package和private级别的成员都是类实现的一部分，不会影响导出的API。
但，该类实现了Serializable时则另当别论。
如果使用protected修饰，则需要注意，该成员时导出的API的一部分。

另外，实例field尽量不要设置为公有。如果一个field不是final或者是一个指向可变对象的final field，公有的访问级别会破坏该field的不可变性，它已不是一个内部的数据表示，而且非线程安全。
当然，这对于长度!=0的数组也是一样的。