设计模式之设计原则

单一职责原则

对一个类而言，应该仅有一个引起它变化的原因。

• 出于考虑
  如果一个类承担承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当变化发生时，设计会遭到意想不到的破坏。
  eg：类T负责两个不同的职责：职责P1，职责P2。当由于职责P1需求发生改变而需要修改类T时，有可能会导致原本运行正常的职责P2功能发生故障。

• 单一职责
  软件设计真正要做的许多内容，就是发现职责并把那些职责相互分离。如果能够想到多于一个的动机去改变一个类，那么这个类就具有多于一个的职责，就应该考虑类的职责分离。
  eg:分别建立两个类T1、T2，使T1完成职责P1功能，T2完成职责P2功能。这样，当修改类T1时，不会使职责P2发生故障风险；同理，当修改T2时，也不会使职责P1发生故障风险。

• 优点

  • 降低类的复杂度
    一个类只负责一项职责，其逻辑肯定要比负责多项职责简单得多。
  • 提高类的可读性，提高系统的可维护性
  • 降低变更引起的风险
    变更是必然的，如果单一职责原则遵守的好，当修改一个功能时，可以显著降低对其他功能的影响。

注意：单一职责原则不只是面向对象编程思想所特有的，只要是模块化的程序设计，都适用单一职责原则。

开放-封闭原则

软件实体（类、模块、函数等等）应该可以扩展，但是不可以修改。
也就是两个原则：

• 对于扩展是开放的；
• 对于更改是封闭的。

• 出于考虑
  面对需求的改变可以保持相对稳定，从而使得系统可以在第一个版本以后不断推出新的版本。
• 如果应对变化
  对于无法对之封闭的变化，应该构造抽象来隔离这些变化
• 意义
  开放-封闭原则是面向对象设计的核心所在。遵循这个原则可以带来面向对象技术所具有的好处：
  
  • 可维护
  • 可扩展
  • 可复用
  • 灵活性好

里氏代换原则

子类型必须能够替换掉它们的父类型。

• 问题由来
  有一功能P1，由类A完成。现需要将功能P1进行扩展，扩展后的功能为P，其中P由原有功能P1与新功能P2组成。新功能P由类A的子类B来完成，则子类B在完成新功能P2的同时，有可能会导致原有功能P1发生故障。
• 解决方法
  当使用继承时，遵循里氏替换原则。类B继承类A时，除添加新的方法完成新增功能P2外，尽量不要重写父类A的方法，也尽量不要重载父类A的方法。
• 解释
  一个软件实体如果使用的是一个父类的话，那么一定适用于其子类，而且它察觉不出父类对象和子类对象的区别。也就是说，在软件里面，把父类对象都替换成它的子类，程序的行为没有变化。（子类可以扩展父类的功能，但不能改变父类原有的功能。）
  
  • 子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法。
  • 子类中可以增加自己特有的方法。
  • 当子类的方法重载父类的方法时，方法的前置条件（即方法的形参）要比父类方法的输入参数更宽松。
  • 当子类的方法实现父类的抽象方法时，方法的后置条件（即方法的返回值）要比父类更严格。

依赖倒转原则

也就是针对接口编程，不要对实现编程。

• 原则
  
  • 高层模块不应该依赖底层模块。两个都应该依赖抽象。
  • 抽象不应该依赖细节。细节应该依赖抽象。
• 问题由来
  类A直接依赖类B，假如要将类A改为依赖类C，则必须通过修改类A的代码来达成。这种场景下，类A一般是高层模块，负责复杂的业务逻辑；类B和类C是低层模块，负责基本的原子操作；假如修改类A，会给程序带来不必要的风险。
• 解决方案
  将类A修改为依赖接口I，类B和类C各自实现接口I，类A通过接口I间接与类B或者类C发生联系，则会大大降低修改类A的几率。
• 实现基础——里氏代换原则
  由于子类型的可替换性才使得父类类型的模块在无需修改的情况下就可以扩展。
• 核心思想——面向接口编程
  面向接口来编程，多个模块共同抽象出一个通用接口，各个模块的实现都依赖于这个通用接口，以后模块实现可以改变，但是通用接口一直不变。这样就减少了模块间的耦合度，提高了模块内的聚合度。
• 在java中
  在java中，抽象指的是接口或者抽象类，细节就是具体的实现类，使用接口或者抽象类的目的是制定好规范和契约，而不去涉及任何具体的操作，把展现细节的任务交给他们的实现类去完成。

迪米特法则（最少知识法则）

如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。如果其中一个类需要调用另一个类的某一个方法的话，可以通过第三者转发这个调用。

• 问题由来
  类与类之间的关系越密切，耦合度越大，当一个类发生改变时，对另一个类的影响也越大。
• 解决方法
  降低类与类之间的耦合。
• 好处
  类之间的耦合越弱，越有利于复用。一个处在弱耦合的类被修改，不会对有关系的类造成波及。

接口隔离原则

客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。

• 问题由来
  类A通过接口I依赖类B，类C通过接口I依赖类D，如果接口I对于类A和类B来说不是最小接口，则类B和类D必须去实现他们不需要的方法。
• 解决方案
  将臃肿的接口I拆分为独立的几个接口，类A和类C分别与他们需要的接口建立依赖关系。也就是采用接口隔离原则。
• 注意
  
  • 接口尽量小，但是要有限度。对接口进行细化可以提高程序设计灵活性是不挣的事实，但是如果过小，则会造成接口数量过多，使设计复杂化。所以一定要适度。
  • 为依赖接口的类定制服务，只暴露给调用的类它需要的方法，它不需要的方法则隐藏起来。只有专注地为一个模块提供定制服务，才能建立最小的依赖关系。
• 提高内聚，减少对外交互。使接口用最少的方法去完成最多的事情。

合成/聚合复用原则

尽量使用合成/聚合，尽量不要使用类继承。

• 聚合
  聚合表示一种弱的“拥有”关系，体现的是A对象可以包含B对象，但B对象不是A对象的一部分。例如大雁跟雁群就是一种聚合关系。
• 合成
  合成是一种强的“拥有”关系，体现了严格的部分和整体的关系，部分和整体的生命周期一样。例如大雁跟翅膀是一种合成关系。

好处

优先使用对象的合成/聚合将有助于保持每个类被封装，并被击中在单个任务上。这样类和类继承层次会保持较小规模，并且不太可能增长为不可控制的庞然大物。