设计模式遵循的七大原则

 

单一职责原则:

“单一职责原则（Single responsibility principle），意思就是说，功能要单一？ 可以简单的这么理解，它的准确解释是：就一个类而言，应该仅有一个引起它变化的原因。我们在做编程的时候，很自然的会给一个类各种各样的功能，比如我们写一个窗体应用程序，一般都会生产一个form这样的类，于是我们把各种各样的代码，想商业运算呀，数据访问sql语句呀，都写到这样的类中，这就意味着，无论什么需求要来，你都要更改这个窗体类，这其实是很糟糕的，维护麻烦，复用不可能，也却反灵活性。”

 

单一职责原则（SRP），就一个类而言，应该仅有一个引起它变化的原因。

 

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

开放封闭原则:

“开放封闭原则（OCP）（Open Closed Principle）：是说软件实体（类、模块、函数等等）应该可以扩展，但是不可以修改。”

 

这个原则其实有两个特征，一个是“对于扩展时开放的”，另一个是“对于更改时封闭的”。

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

 

设计软件要容易维护有不容易出问题的最好的办法，就是多扩展，少修改。开放封闭原子的意思就是说，设计的时候，时刻要考虑，尽量让这个类足够好，写了就不要去修改了，如果新的需求来，我们增加一些类就好了，原来的代码能不动就不懂。但是无论多么的封闭，都会存在一些无法对之封闭的变化。既然不可能完全封闭，设计人员必须对于他设计的模块应该对哪种变化封闭做出选择。他必须先猜出最有可能变化的种类，然后构造抽象来隔离那些变化。但是变化时很难预测的，但我们可以在发生小变化时，就及早去想办法应对发生更大变化的可能。也就是等到变化发生时立即采取行动。

在我们最初编写代码时，假设变化不会发生。当发生变化时，我们就创建抽象来隔离以后发生的同类变化。面对需求对程序的改动是增加新代码进行的，而不是改现有的代码。这是开放封闭原则的精神所在。

 

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

依赖倒转原则:

本节先是通过小菜为妹纸修电脑的例子引出了电脑制造的一个原则：内部封转，明确接口，统一标准。具体说来就是，各个部件的具体实现和制造不尽相同，但是他们都遵循一个接口标准，使得各个部件可以无缝的链接起来；同时在这个接口之上可以进行有限的扩展。电脑配件之间的关系还体现另一个基本原则：强内聚，松耦合。

电脑配件还体现了前面说过两个原则，单一职责原则和开放封闭原则。这里着重强调一个新的原则，叫依赖倒转原则（DIP）（Dependence Inversion Principle）。依赖倒转原则，原话解释是抽象不应该依赖细节，细节应该依赖于抽闲。说白了，就是要针对接口编程，不要对实现编程。回到例子上，主板，cpu等都是针对接口设计的，如果针对实现来设计，内存就要对应到具体的某个品牌的主板，就会出现换内存需要把主板也换了的尴尬。

依赖倒转原则：

A. 高层模块不应该依赖底层模块。两个都应该依赖抽象。

B. 抽象不应该依赖细节。细节应该依赖抽象。

为什么需要依赖倒转？面向对象开发时，为了使得常用代码可以复用，一般都会把这些代码写出许多的函数程序库，新项目中去调用这些底层的函数就可以了。比如数据库访问模块等。问题也出在这里，当有新项目时，发现业务逻辑的高层模块都是一样的， 但客户却希望使用不同的数据库或存储信息的方式。我们希望再次利用这些高层模块，但高层模块与低层模块绑定在一起的，没法复用这些高层模块，这就麻烦了。而如果不管高层还是低层模块，它们都依赖于抽象，具体一点就是借口或者抽象类，只要借口是稳定的，那么任何一个的更改都不用担心受其它受到影响。这就使得无论高层还是低层模块都可以很容易的被复用。

但为什么依赖了抽象的接口或抽象类，就不怕更改呢？这里需要讲到里氏代换原则。具体说来是一个软件实体如果使用的是一个父类的话，那么一定适用于其子类，而且察觉不出父类和子类对象的区别。也就是说，在软件里面，把父类都替换成它的子类，程序的行为没有变化。简单来说，子类型必须能够替换掉他们的父类型。为什么需要这样呢？只有当子类可以替换掉父类，软件单位的功能不受到影响时，父类才能真正被复用，而子类也能够在父类的基础上增加新的行为。

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

 

 

再回头来看依赖倒转原则，高层模块不应该依赖低层模块，两个都应该依赖抽象，如下图：

 

里氏代换原则:

里氏代换原则（LSP）（Liskov Substitution Principle LSP）：子类必须能够代替它们的父类型。这里的父类型也可指接口。这个原则其实是对开放-封闭原则的补充。因为开发-封闭原则的核心就是抽象化，而里氏代换原则则是抽象化的规范。

 

一个软件实体如果使用的是一个父类的话，那么一定适用于其子类，而且它察觉不出父类对象和子类对象的区别，也就是说，在软件里面，把父类都替换成它的子类，程序的行为没有变化，简单的说，子类型必须能够替换掉它们的父类型。也正因为有了这个原则，使得继承复用成为了可能，只有当子类可以替换掉父类，软件单位的功能不受到影响时，父类才能真正被复用，而子类也能够在父类的基础上添加新的行为。

 

比方说，猫是继承动物类的，以动物的身份拥有吃、喝、跑、叫等行为，可当某一天，我们需要狗、牛、羊也拥有类似的行为，由于他们都是继承与动物，所以除了更改实例化的地方，程序其他处不需要修改。正式有了里氏代换原则，才使得开放-封闭成为了可能。由于子类型的可替换性才使得使用父类类型的模块在无需修改的情况下就可以扩展。

迪米特法则:

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

1.迪米特法则首先强调的前提是在类的结构设计上，每一个类都应当尽量降低成员的访问权限，也就是说，一个类包装好自己的private状态，不需要让别的类知道的字段或行为就不要公开。
2.类之间的耦合越弱，越有利于复用，一个处在弱耦合的类被修改，不会对有关系的类造成波及。也就是说，信息的隐藏促进了软件的复用。