[设计模式]-架构中的设计原则(笔记ing)

用抽象构建框架，用实现扩展细节

1、单一职责原则(SRP)

核心思想：系统中每一个对象都应该只有一个单独的职责，而所有对象所关注的就是自身指责的完成。

SRP就是我们所说的"高内聚、低耦合"

优点：消除耦合

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

2、里氏替换原则(LSP)

核心思想：在任何父类出现的地方都可以用子类来替代

LSP通俗的来讲就是：子类可以扩展父类的功能，但不能改变父类原有的功能。它包含4层含义：

• 子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法。
• 子类中可以增加自己特有的方法。
• 当子类的方法重载父类的方法时，方法的前置条件（即方法的形参）要比父类方法的输入参数更宽松。
• 当子类的方法实现父类的抽象方法时，方法的后置条件（即方法的返回值）要比父类更严格。

  LSP关注的是怎样良好的使用继承，也就是说不要滥用继承，它是继承复用的基石

  经典”正方形不是矩形“的问题。

  。。。

3、依赖倒置原则(DIP)

核心思想：要依赖于抽象，不要依赖于具体实现

DIP的意思是：在应用程序中，所有的类如果使用或依赖于其他的类，则都应该依赖于这些其他类的抽象类，而不是这些其他类的具体实现类。抽象层次应该不依赖于具体的实现细节，这样才能保证系统的可复用性与可维护性。因此为实现这一原则，我们要在编程时针对接口编程，而不针对实现编程。

• 低层模块尽量都要有抽象类或接口，或者两者都有。
• 变量的声明类型尽量是抽象类或接口。
• 使用继承时遵循里氏替换原则。
  

4、接口分离原则(ISP)

核心思想：不应该强迫客户程序依赖它们不需要使用的方法

ISP的意思是：一个接口应该只提供一种对外的功能，不应该把所有的操作都封装到一个接口中（这里的接口分两种：对象接口(类)，类接口(Class Interface),P30）。

也就是说，ISP要求在一个模块中应该只依赖它需要的接口，以保证接口的小纯洁。而且需要接口尽量小，即设计接口时应尽量细化，不要定义太臃肿的接口。

与单一职责原则比较：

• 单一职责原则要求类与接口职责单一，注重的是职责，是业务逻辑上的划分。而接口分离原则注重对接口依赖的隔离
• 单一职责原则主要是约束类，其次才是接口和方法，它针对的是程序中的实现和细节；而接口分离原则主要约束接口，主要针对抽象，针对程序整体框架的构建

5、迪米特原则(LOD)-最少知识原则(LKP)

核心思想：一个对象应当对其他对象尽可能少的了解。即降低对象之间的耦合

更简单的定义：只与直接的朋友通信--<观察者模式？>

LOD的核心观念是类间解耦，弱耦合。只有弱耦合了以后，类的复用性才可以提高

过分的使用迪米特原则，会产生大量的中介和传递类，导致系统复杂度变大。所以在采用迪米特法则时要反复权衡，既做到结构清晰，又要高内聚低耦合

6、开闭原则(OCP)

核心思想：一个对象应对扩展开放，对修改关闭

OCP的意思是：软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码。也就是说，开发人员一旦写出了可以运行的代码，就不应去改变它，而是要保证它能一直运行下去，如何做到这一点呢？这就需要借助抽象与多态，即把可能变化的内容抽象出来，从而使抽象的部分是相对稳定的，而具体的实现层则是可以改变和扩展的。

开闭原则算是前5种原则的一个抽象总结，前5种是开闭原则的一些具体实现。