设计模式-第3章（设计原则）

单一职责原则

设计模式中有一个非常重要的原则 — 单一职责。
单一职责原则（SRP）：就一个类而言，应该仅有一个引起它变化的原因。

我们在做编程的时候，很自然地就会给一个类加各种各样的功能，比如我们写一个窗体应用程序，一般都会生成一个Form1这样的类，于是我们就把各种各样的代码，像某种商业运算的算法呀，像数据库访问的SQL语句呀什么的都写到这样的类当中，这就意味着，无论任何需求要来，你都需要更改这个窗体类，这其实是很糟糕的，维护麻烦，复用不可能，也缺乏灵活性。

方块游戏的设计
以俄罗斯方块游戏为例：可以将界面绘画和游戏逻辑分开，分为两个类，一个类负责绘制页面，一个类实现游戏逻辑。实现类的单一职责，增加了代码可维护性，灵活性，可扩展性。

如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当变化发生时，设计会遭受到意想不到的破坏。

软件设计真正要做的许多内容，就是发现职责并把那些职责相互分离。其实要去判断是否应该分离出类来，也不难，那就是如果你能够想到多于一个的动机去改变一个类，那么这个类就具有多于一个的职责，就应该考虑类的职责分离。

单一职责的优点：实现类的单一职责，代码才能真正的易维护，易扩展，易复用，灵活多样。

开放-封闭原则

开发封闭原则，是说软件实体（类，模块，函数等）应该可以扩展，但是不可修改。
这个原则其实是有两个特征，一个是说对于扩展是开放的，另一个是说对于更改是封闭的。

我们在做任何系统的时候，都不要指望系统一开始时需求确定，就再也不会变化，这是不现实也不科学的想法，而既然需求是一定会变化的，那么如何在面对需求的变化时，设计的软件可以相对容易修改，不至于说，新需求一来，就要把整个程序推倒重来。怎样的设计才能面对需求的改变却可以保持相对稳定，从而使得系统可以在第一个版本以后不断推出新的版本呢?，开放-封闭给我们答案。

要想使得软件容易维护又不容易出问题的最好的办法，就是多扩展，少修改。

开放-封闭原则的意思就是说，设计的时候，时刻要考虑，尽量让这个类是足够好，写好了就不要去修改了，如果新需求来，我们增加一些类就完事了，原来的代码能不动则不动。

绝对的对修改关闭是不可能的。无论模块是多么的封闭，都会存在一些无法对之封闭的变化。既然不可能完全封闭，设计人员必须对于他设计的模块应该对哪种变化封闭做出选择。他必须先猜测出最有可能发生的变化种类，然后构造抽象来隔离那些变化。

在我们最初编写代码时，假设变化不会发生。当变化发生时，我们就创建抽象来隔离以后发生的同类变化。

在客户端中使用了加法类。

如果在原有的基础上再增加减法功能，最好的做法不是再加法类上增加减法功能，而是增加出一个抽象的运算类，继承抽象类实现减法类。这样做的好处是，可以在以后增加乘法和除法功能时，直接增加乘法类和除法类就可以了。

面对需求，对程序的改动是通过增加新代码进行的，而不是更改现有的代码。

并不是什么时候应对变化都是容易的。我们希望的是在开发工作展开不久就知道可能发生的变化。查明可能发生的变化所等待的时间越长，要创建正确的抽象就越困难。

开放-封闭原则是面向对象设计的核心所在。 遵循这个原则可以带来面向对象技术所声称的巨大好处，也就是可维护、可扩展、可复用、灵活性好。开发人员应该仅对程序中呈现出频繁变化的那些部分做出抽象，然而，对于应用程序中的每个部分都刻意地进行抽象同样不是一个好主意。拒绝不成熟的抽象和抽象本身一样重要。切记，切记。

依赖倒转原则

把PC电脑理解成是大的软件系统，任何部件如CPU、内存、硬盘、显卡等都可以理解为程序中封装的类或程序集，由于PC 易插拔的方式，那么不管哪一个出问题，都可以在不影响别的部件的前提下进行修改或替换。

PC电脑里叫易插拔，面向对象里把这种关系叫强内聚、低耦合吧。

CPU的对外都是针脚式或触点式等标准的接口。CPU只需要把接口定义好，内部再复杂我也不让外界知道，而主板只需要预留与CPU针脚的插槽就可以了。这就是接口的最大好处。

无论主板、CPU、内存、硬盘都是在针对接口设计的，主板针对预留的CPU针脚的插槽进行设计，而不需要知道CPU内部是如何设计的，CPU也是针对主板预留的CPU插槽进行设计，而不需要管主板是如何实现的。

依赖倒转原则，抽象不应该依赖细节，细节应该依赖于抽象。说白了，就是要针对接口进行编程，不要针对实现编程。

依赖倒转原则

• 高层模块不应该依赖低层模块。两个都应该依赖抽象。
• 抽象不应该依赖细节。细节应该依赖抽象。

高层模块如果依赖与底层模块，如果改变了低层模块中的代码，那么高层模块也要跟着改变。

如果高层模块和低层模块，它们都依赖于抽象，具体一点就是接口或抽象类，只要接口是稳定的，那么任何一个的更改都不用担心其他受到影响，这就使得无论高层模块还是低层模块都可以很容易地被复用。这才是最好的办法。

为什么依赖了抽象的接口或抽象类，就不怕更改了呢？因为里氏代换原则！

里氏代换原则(LSP):子类型必须能够替换掉它们的父类型。

就是一个软件实体如果使用的是一个父类的话，那么一定适用于其子类，而且它察觉不出父类对象和子类对象的区别。也就是说，在软件里面，把父类都替换成它的子类，程序的行为没有变化。

也正因为有了这个原则，使得继承复用成为了可能，只有当子类可以替换掉父类，软件单位的功能不受到影响时，父类才能真正被复用，而子类也能够在父类的基础上增加新的行为。

比方说，猫是继承动物类的，以动物的身份拥有吃、喝、跑、叫等行为，可当某一天，我们需要狗、牛、羊也拥有类似的行为，由于它们都是继承于动物，所以除了更改实例化的地方，程序其他处不需要改变。

// 当需求有变化是，可以将猫换成狗，牛，羊别的动物，程序的其它地方并不需要修改。
动物 animal = new 猫();
animal.吃喝();
animal.移动();

由于有里氏代换原则，才使得开放-封闭成为了可能。
正是由于子类型的可替换性才使得使用父类类型的模块在无需修改的情况下就可以扩展。不然还谈什么扩展开放，修改关闭呢。

依赖倒转其实可以说是面向对象设计的标志，用哪种语言来编写程序不重要，如果编写时考虑的都是如何针对抽象编程而不是针对细节编程，即程序中所有的依赖关系都是终止于抽象类或者接口，那就是面向对象的设计，反之那就是过程化的设计了。

迪米特法则

迪米特法则，也叫最少知识原则。

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

迪米特法则首先强调的前提是在类的结构设计上，每一个类都应当尽量降低成员的访问权限。一个类包装好自己的private状态，不需要让别的类知道的字段或行为就不要公开。

迪米特法则的根本思想，是强调了类之间的松耦合。

示例：小菜去公司报到，人事安排IT部门给小菜装电脑，IT 部主管安排小张给小菜装电脑，由于小张临时有事，IT部主管又安排其他人给小菜装电脑。
小菜和IT部的关系，小菜不必知道是谁具体的帮他装电脑，只需要和IT部打交道即可，就算小张有事，IT部还有其他人。

类之间的耦合越弱，越有利于复用，一个处在弱耦合的类被修改，不会对有关系的类造成波及。
信息的隐藏，促进了软件的复用。