设计模式六大原则（大话设计模式kotlin版）

单一职责原则 SRP（Single Responsibility Principle）

---

• 定义：就一个类而言，应该仅有一个引起它变化的原因。（简单来说就是类的职责要单一，但职责的单一不一定指只定义一个方法，它指的是功能性或模块性的一致性）
• 分析：如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能或削弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当职责发生变化时，设计可能会遭受到意想不到的破坏。
• 该怎么分离？

1. 软件设计真正要做的许多内容，就是发现职责并把哪些职责相互分离。
2. 如果你有多一个动机去改变一个类，那么这个类就多一个职责，就应该考虑类的职责分离。

• 好处： 遵循此原则有利于开发出可维护、可拓展、可复用、灵活性好的程序。
• 案例： 程序UI界面是通常易变的，里面算法逻辑若是不经常变化，将他们分离有助于界面的改动。整合是一种好的思想。但包含在这个整体的每一个小的粒度内也应该尽可能让每一个类承担少的职责。（个人理解）

开放-封闭原则 OCP（Open-Close Principle）

---

• 定义：是说软件实体（类、模块、函数等等）应该可以拓展，但是不可以修改。
• 特征：

1. 对于拓展开放的。
2. 对于更改是关闭的。

• 如何设计？

1. 设计一个类之初，无法预知它会发生哪些变化，等到变化的时才立即采取行动。
2. 类需要变化的时候，通过创建抽象类来隔离以后发生的同类变化。例如，简单工厂模式的应用中，将加减乘除法的运算抽象出一个运算类，而不是在一个类中写全部运算的实现。
3. 尽可能在类发生小变化的时候就去抽象，否则等到后面此类应用在多处，再考虑分离抽象就很难了。
4. 开发人员应仅对程序中程序频繁的变化做出部分抽象，而不是应用程序的每一个部分 都刻意进行抽象。

• 好处：

1. 开放-封闭原则是面向对象程序设计的核心。
2. 遵循此原则有利于开发出可维护、可拓展、可复用、灵活性好的程序。

• 案例： 香港与澳门的一国两制制度。

依赖倒置原则 DIP（Dependency Inversion Principle）

---

• 定义：

1. 高层模块不应该依赖于低层模块。两个都应该依赖于抽象。
2. 抽象不应该依赖于细节。细节应该依赖于抽象。说白了就是针对接口编程，不要针对实现编程。（示例请参考建造者模式）

• 分析：
  
  高层模块：这里指业务逻辑层。
  低层模块：这里指提供特有的解决行为。例如，访问数据库代码。
  若此时需要更换低层访问数据库代码（将MySQL改成Oracle），如果低层模块封装得不够好，由于高层模块可能有多处依赖低层模块，由于他们相互绑定，会使更改低层的数据库访问代码会严重影响高层的业务逻辑。

• 解决：
  
  将高层模块与低层模块都依赖于抽象（抽象类或接口），只要抽象是稳定的，那么任何一个（高层或低层）的更改都不会影响其他的模块，这就使得模块更容易地被复用。

• 小结：即面向接口编程。

里氏替换原则 LSP（Liskov Substitution Principle）

---

• 定义：子类型必须能够替换掉他们的父类型。一个软件实体如果使用的是一个父类的话，那么一定使用于其子类，而它察觉不出父类对象和子类对象的区别。也就是说在软件里，把父类替换成它的子类，程序的行为没有变化。
• 分析：

1. 在面向程序设计时，一个是鸟类，一个是企鹅类，如果定义鸟是可以飞的，在生物学分类上属于鸟类的企鹅（不会飞），那在程序世界里因为企鹅不具备飞的条件，所以企鹅不能继承鸟这个类。继承意味着子类拥有父类所有非private的行为和属性，鸟类的具有会飞的行为，而企鹅不具备，那么企鹅就无法以父类（鸟类）的身份出现。
   
2. 只有当子类可以替换掉父类，软件单位的功能不受到影响，父类才能真正被复用，而子类也能够在父类的基础上增加新的行为。

• 好处：

1. 有此原则才让开放-封闭原则成为可能。
2. 由于子类型的可替换性才使得使用父类型的模块在无需修改的情况下就可以拓展。

迪米特法则 LoD（Law of Demeter）

---

• 定义：如果两个类不必彼此直接通信，那么这两个类就不应当发送直接的相互作用。如果其中一个类需要调用另一个类的某一个方法的话，可以通过第三者转发这个调用。它也叫最少知识原则。中介模式是它的一种应用。
• 强调前提：在类的结构设计上，每一个类都应当尽量的降低成员的访问权限；即一个类包装好自己的private状态，不需要让别的类知道的字段或行为就不要公开。
• 根本思想：强调类之间的松耦合。
• 优势：类之间的耦合越弱，越有利于复用，一个处在弱耦合的类被修改，不会对有关系的类造成波及。换句话说，信息的隐藏促进了软件的复用。

接口隔离原则ISP（Lnterface Segregation Principle）

---

引用原文：面向对象设计原则之接口隔离原则

• 定义：使用多个专门的接口，而不使用单一的总接口，即客户端不应该依赖那些它不需要的接口。

• 分析： 根据接口隔离原则，当一个接口太大时，我们需要将它分割成一些更细小的接口，使用该接口的客户端仅需知道与之相关的方法即可。每一个接口应该承担一种相对独立的角色，不干不该干的事，该干的事都要干。这里的“接口”往往有两种不同的含义：一种是指一个类型所具有的方法特征的集合，仅仅是一种逻辑上的抽象；另外一种是指某种语言具体的“接口”定义，有严格的定义和结构，比如Java语言中的interface`。对于这两种不同的含义，ISP的表达方式以及含义都有所不同：

1. 当把“接口”理解成一个类型所提供的所有方法特征的集合的时候，这就是一种逻辑上的概念，接口的划分将直接带来类型的划分。可以把接口理解成角色，一个接口只能代表一个角色，每个角色都有它特定的一个接口，此时，这个原则可以叫做“角色隔离原则”
2. ) 如果把“接口”理解成狭义的特定语言的接口，那么ISP表达的意思是指接口仅仅提供客户端需要的行为，客户端不需要的行为则隐藏起来，应当为客户端提供尽可能小的单独的接口，而不要提供大的总接口。在面向对象编程语言中，实现一个接口就需要实现该接口中定义的所有方法，因此大的总接口使用起来不一定很方便，为了使接口的职责单一，需要将大接口中的方法根据其职责不同分别放在不同的小接口中，以确保每个接口使用起来都较为方便，并都承担某一单一角色。接口应该尽量细化，同时接口中的方法应该尽量少，每个接口中只包含一个客户端（如子模块或业务逻辑类）所需的方法即可，这种机制也称为“定制服务”，即为不同的客户端提供宽窄不同的接口。

• 小结：

1. 在使用接口隔离原则时，我们需要注意控制接口的粒度，接口不能太小，如果太小会导致系统中接口泛滥，不利于维护；接口也不能太大，太大的接口将违背接口隔离原则，灵活性较差，使用起来很不方便。一般而言，接口中仅包含为某一类用户定制的方法即可，不应该强迫客户依赖于那些它们不用的方法。
2. 接口也要遵循单一职责原则，所以可以理解为：接口隔离原则由单一职责原则演化而来。职责单一不一定指只定义一个方法，指的是功能性或模块性的一致性。