Java设计模式（二）----设计原则

• 单一职责原则

  • Single Responsibility Principle，简称SRP
  • 定义

  一个类，应当只有一个引起它变化的原因；即一个类应该只有一个职责。

  • 单一职责原则的优点有以下几个方面：

  1、降低类的复杂性；
  2、提高类的可读性；
  3、提高代码的可维护性和复用性；
  4、降低因变更引起的风险。

• 里氏替换原则

  • Liskov Substitution Principle，简称LSP
  • 定义

  所有引用基类的地方必须能透明地使用其子类对象。清晰明确地说明只要父类能出现的地方子类就可以出现，而且替换为子类也不会产生任何错误或异常，使用者可能根本就不需要知道父类还是子类；但是反过来则不可以，有子类的地方，父类未必就能适应。

  • 应用

  在编译期，Java语言编译器会检查一个程序是否符合里氏替换原则，这是一个无关实现的、纯语法意义上的检查。里氏替换要求凡是使用基类的地方，子类一定适用，因此子类必须具备基类的全部接口。或者说，子类型的接口必须包括全部的基类的接口，而且还有可能更宽。如果一个Java程序破坏这一条件，Java编译器就会在编译程序时抛出错误提示，并停止编译

• 依赖倒置原则

  • Dependence Inversion Principle，简称DIP。
  • 定义

  ■ 高层模块不应该依赖低层模块，两者都依赖其抽象；
  ■ 抽象不依赖细节；
  ■ 细节应该依赖于抽象。

• 接口隔离原则

  • Interface Segregation Principle，简称ISP。
  • 定义

  ■ 一个类对另外一个类的依赖性应当是建立在最小的接口上的。
  ■ 一个接口代表一个角色，不应当将不同的角色都交给一个接口。没有关系的接口合并在一起，形成一个臃肿 的大接口，这是对角色和接口的污染。因此使用多个专门的接口比使用单一的总接口要好。
  ■ 不应该强迫客户依赖于它们不用的方法。接口属于客户，不属于它所在的类层次结构，即不要强迫客户使用它们不用的方法，否则这些客户就会面临由于这些不使用的方法的改变所带来的改变。

• 迪米特法则

  • Law of Demeter，简称LoD。
  • 定义

  ■ 只与你直接的朋友们通信（Only talk to your immediate friends）；
  ■ 不要跟“陌生人”说话（Don’t talk to strangers）；
  ■ 每一个软件单位对其他的单位都只有最少的了解，这些了解仅局限于那些与本单位密切相关的软件单位。

按照迪米特法则，如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用；如果一个类需要调用另一个类的某一个方法，可以通过第三者转发这个调用。
例如，“某人”与一个“朋友”组成自己的朋友圈，两个人都需要与一个圈外的“陌生人”发生相互作用，不符合迪米特法则的类图如下图所示。

其实，“某人”没有必要与“陌生人”直接发生相互作用，他可以通过“朋友”间接与“陌生人”发生作用，如下图所示的类图符合迪米特法则。

• 开闭原则
  • Open-Closed Principle，简称OCP
  • 定义

  一个软件实体应当对扩展开放，对修改关闭。
  这个原则说的是，在设计一个模块的时候，应当使这个模块可以在不被修改的前提下被扩展，即应当可以在不必修改源代码的情况下改变这个模块的行为。

在面向对象的编程中，开闭原则是最基础的原则，起到总的指导作用，其他原则（单一职责、里氏替换、依赖倒置、接口隔离、迪米特法则）都是开闭原则的具体形态，即其他原则都是开闭原则的手段和工具。开闭原则的重要性可以通过以下几个方面来体现。

• 开闭原则提高复用性。在面向对象的设计中，所有的逻辑都是从原子逻辑组合而来的，而不是在一个类中独立实现一个业务逻辑，代码粒度越小，被复用的可能性就越大，避免相同的逻辑重复增加。开闭原则的设计保证系统是一个在高层次上实现了复用的系统。
• 开闭原则提高可维护性。一个软件投产后，维护人员的工作不仅仅是对数据进行维护，还可能对程序进行扩展，就是扩展一个类，而不是修改一个类。开闭原则对已有软件模块，特别是最重要的抽象层模块要求不能再修改，这就使变化中的软件系统有一定的稳定性和延续性，便于系统的维护。
• 开闭原则提高灵活性。所有的软件系统都有一个共同的性质，即对系统的需求都会随时间的推移而发生变化。在软件系统面临新的需求时，系统的设计必须是稳定的。开闭原则可以通过扩展已有的软件系统，提供新的行为，能快速应对变化，以满足对软件新的需求，使变化中的软件系统有一定的适应性和灵活性。
• 开闭原则易于测试。测试是软件开发过程中必不可少的一个环节。测试代码不仅要保证逻辑的正确性，还要保证苛刻条件（高压力、异常、错误）下不产生“有毒代码”（Poisonous Code），因此当有变化提出时，原有健壮的代码要尽量不修改，而是通过扩展来实现。否则，就需要把原有的测试过程回笼一遍，需要进行单元测试、功能测试、集成测试，甚至是验收测试。开闭原则的使用，保证软件是通过扩展来实现业务逻辑的变化，而不是修改。因此，对于新增加的类，只需新增相应的测试类，编写对应的测试方法，只要保证新增的类是正确的就可以了。