设计模式的原则

单一职责原则

• There should never be more than one reason for a class to change
  这是单一职责的概念，单一职责从名称上来说很好理解。借用《设计模式之禅》的一个例子来看。

  
  接近的例子
  

  之上的例子看起来已经功能划分已经做的很好了，但是我们还可以进一步的区分它。

  
  划分后的类图
  这样分割起来功能结构更加的清晰了。
  单一职责原则的好处有：
• 类的复杂性降低，实现什么职责都有清晰明确的定义；
• 可读性提高，复杂性降低，那当然可读性提高了；
• 可维护性提高，可读性提高，那当然更容易维护了；
  很多时候，我们所说的单一职责指的都是接口的单一职责，类的单一职责很多时候很难遵守。

里氏替换原则

定义：如果对每一个类型为S的对象o1，都有类型为T的对象o2，使得以T定义的所有程序P在所有的对象o1都代换成o2时，程序P的行为没有发生变化，那么类型S是类型T的子类型。
它有如下的规则：
1.子类必须完全实现父类的方法。
2.父类出现的地方，子类可以替换。
3.子类可以拥有自己的个性，但是尽量避免。
4.覆盖或者实现父类方法的时候输入参数可以被放大。
5.覆盖或者实现父类方法的时候输出参数可以被缩小。

依赖倒置原则

主要包含三层含义：

• 高层模块不应该依赖低层模块，两者都应该依赖其抽象；
• 抽象不应该依赖细节；
• 细节应该依赖抽象。
  这些原则在我们平时开发的时候潜移默化应该就已经在遵守了。
  在之上的基础上，我们可以衍生出一些概念来。比如，每个类尽量都有接口或者抽象类。任何类都不应该从具体的类中派生。尽量不要复写基类方法。

接口隔离原则

总结：客户端不应该依赖它不需要的接口，类的依赖关系之间应该建立在最小的接口上。
我们都知道，接口的粒度设计的越小，系统越加灵活。接口隔离是对接口的定义也是对类的定义。接口和类尽量使用原子接口和原子类来定义。在上述的要求中，我们尽量的满足之下的要求：

• 一个接口只服务于一个子模块或者业务逻辑。
• 有需要修改的接口尽量去修改，否则使用适配器模式去适配。

迪米特法则

也称为最小知识原则，一个对象应该对其他对象有最小的了解。也就是说一个类只和他的朋友类进行联络。朋友类的定义是这样的：出现在成员变量、方法的输入输出参数中的类称为成员朋友类，而出现在方法体内部的类不属于朋友类。
总之，迪米特法则的核心观念就是类直接的解耦，弱耦合。只有如此才能提高类之间的复用性。

开闭原则

开闭原则的定义是对扩展开放，对修改关闭。举个例子来说，如果我们的上层服务依赖了一个底层服务。这个底层服务的升级不能对原有的接口功能有变动，而是应该去扩展它的功能，保证变动不影响上层服务的使用。具体的细化标准我认为可以参照语义化版本。
假设标准的语义化版本号为X.Y.Z

• X：主版本号，当我们做了不兼容或者颠覆性的更新，修改此版本号。
• Y：此版本号，当我们做了向下兼容的功能性修改，修改此版本号。
• Z：修订号，当我们做了向下兼容的问题修正，修改此版本号。

如果底层服务升级了主版本号，在旧版本还有用户的情况下， 应该坚持维护多套版本服务。
但很多时候，开闭原则是一个精神口号，需要实现拥抱的变化特别多，仅仅知道一个开闭原则是不够的。可以说开闭原则是之上所提到的原则的抽象类。它是一个总的目标。