面向对象的原理

开放封闭原理（Open Closed Principle）
类应该是开放的以便于扩展，又要是封闭的以利于修改。我们应该可以在不改动原有类的基础上，就能在系统中增加新的功能。原则就是减少类之间的耦合，在抽象层次上建立类之间的关联。
例子：一家公司对个人客户提供了不同类型的帐户，客户可以在帐户中存款。

Account类在抽象层次与AccountType继承树之间关联。由于Savings和Checking继承了AccountType，就可以利用动态绑定。如果我们创建新类型MoneyMarket，并不需要对原有的类进行改动，达到的OCP的要求。

替代原理（Liskov Substitution Principle）
子类应该可以用来替代其基类。
依赖性倒置原理（Dependency Inversion Principle）
依赖于抽象类，不要依赖于具体类。在Java中，当我们引用类创建实例时，就已经违背了DIP，解决办法有两种：
第一，通过Class类的newInstance方法来动态加载对象。
第二，使用对象工厂。创建一个类来负责创建对象实例。在工厂中使用了具体类，事实上违背了DIP，但这是被隔离的并且经过精心的考虑，是可以接受的。
具体的引用并不总是坏事。如果被引用的是稳定的类，不大会改动，使用工厂就会在系统中引入无根据的复杂性。

抽象耦合
它是指一个类不要与可实例化的类耦合，而应该与它的基类或抽象类耦合。在Java中，抽象类可以是有抽象方法的类，也可以是接口。这实际上是LSP实现其灵活性所必须的方法，是DIP所必须的机制，也是OCP的核心思想。

接口分离原理（Interface Segregation Principle）
多个专用接口优于一个单一的通用接口。所定义的任何接口都应具有高内聚性。在设计接口及接口的的操作时，不要让接口具有多重角色。一个接口应该保证实现该接口的类的实例对象可以只呈现为单一的角色。
例子：实现一个对各种不同的数据源进行统一访问，后台的数据源可能是关系数据库也可能是一般的文件。我们需要提供一个通用的数据访问机制，向任何可能作为数据客户的类提供一致的数据访问模型。

RowSetManager接口的有内聚性的问题：如果实现该接口的类是只读的，不需要插入、更新呢？如果客户端不关心数据获取，只想遍历已经获取的内部数据数据集呢？
经过分析，我们提供一些更专有的接口是很有意义的。
改进例子：

我们把RowSetManager的职责分割到多个接口，每个接口都担负着让类归从于一组内聚的职责。

构成重用原理（Composite Reuse Principle）
对象构成的多态优于继承。面向对象系统中，最具灾难性的错误就是把继承作为重用的主要机制。
例子：

我们在AccountType中增加了一个计算帐户利息的方法。这样做似乎还不错，Savings和MoneyMarket类都是有利息的帐户。而Checking则是无利息的帐户，我们可以简单的在Checking中实现一个空的操作，这个问题暂时解决了。
假如我们又有了新的需求。需要支持一种新的帐户类型Stock。Stock也需要计算利息，得Stock的计算方法与AccountType中定义的缺省实现不一样。我们也可以像Checking的做法一样，只不过实现了适合的算法，而不是空操作。到这时，一切都运行良好。新的需求出现了，MoneyMarket的利息计算方法要改成与Stock相同的机制，Savings还使用原来的机制。
我们有三个解决这个问题的办法：
  第一种是采用新的算法重新改写AccountType的calculateInterest方法，然后用旧的算法为Savings实现一个新的方法。这种办法并不理想，因为它使我们改动了两个原有的类。
  第二种是在MoneyMarket上重写calculateInterest方法，把Stock中的代码复制过来。很显然，这也不是很好的解决办法。重用的目的可不是复制和粘贴代码。
  第三种方法，我们可以定义一个InterestCalculator类，在其它的基础上定义calculateInterest方法实现新的算法，然后把Stock和MoneyMarket中对利息计算移到新的类中。这种方法是我们一开始就应该采用的，这就是使用多态性的构成而不是继承来实现复用。
第三种方法的类图：

再次改进例子：

我们把与InterestCalculator的关系从派生类移到了基类AccountType中，实际上，我们又回到采用继承来实现征用，虽然存在一点差别。对于Checking我们可以使用一个空的算法实现来解决。
如果我们要在基类中定义缺省的行为的话，一定要确保这个行为适用于所有的派生类。