0、设计模式遵循的六大原则

这里说的设计模式遵循的原则也是我们常听到的面向对象设计、系统设计、接口设计时所遵循的几大原则！

一、单一职责原则

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

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

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


二、开放—封闭原则（开闭原则）


开闭原则：软件实体（类、模块、函数等等）应该可以扩展，但是不可修改。

    对于扩展是开发的（Open for extension），对于更改是封闭的（Closed for modification）。

    怎样的设计才能面对需求的改变却可以保持相对稳定，从而使得系统可以在第一个版本以后不断推出新的版本？开闭原则给了我们答案

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

    我们很难预先猜测，但是我们却可以在发生小的变化时，就及早去想办法应对发生更大变化的可能，等到变化发生时立即采取行动。

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

    面对需求，对程序的改动是通过增加新代码进行的，而不是更改现有的代码，这就是开闭原则的精神所在。


三、依赖倒转原则（依赖倒置原则）

依赖倒转原则：抽象不应该以来细节，细节应该依赖于抽象。针对接口编程，不要对实现编程。
A.高层模块不应该依赖底层模块。两个都应该依赖抽象。
B.抽象不应该依赖细节。细节应该依赖抽象。

下面的里氏代换原则有助于理解依赖倒转原则。

四、里氏代换原则

里氏代换原则：子类型必须能够替换掉他们的父类型。

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

    只有当子类可以替换掉父类，软件单位的功能不受到影响时，父类才能真正被复用，而子类也能够在父类的基础上增加新的行为

    正是由于子类型的可替换性才使得使用父类型的模块在无需修改的情况下就可以扩展。

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

五、接口隔离原则

接口隔离原则：不应该强迫客户依赖于它们不用的方法。一个类对另一个类的依赖性应当是建立在最小的接口上。

    我们经常发现有些公司的代码中有一个大接口，里面放着一大堆方法，有些方法根本没有作用。其结果必然导致开发人员将不需要实现的方法多次放置在接口中，造成一定程度的代码冗余。

    在系统开发时，如果有一个职责gaib改变了，那么我们就去修改这个接口？这个接口有多少个实现类，我们就要去修改多少个类。如果我们运用接口隔离原则，一开始就设计角色独立的接口，这种情况就不会出现。

    如何实现接口隔离？

    首先，从业务逻辑角度考虑接口，我们可以把某类功能也设计成接口。

    其次，根据场合和调用者的情况，消除无关的方法，只提供同类型角色的接口。

    再次，我们对客户程序进行有效区分，并对其对应的接口进行变化。比如，当客户程序又乱又杂，此时我们就需要对其进行隔离。随着客户程序的分离，其对应的接口也随之变化。

    如此一来，分离的客户程序与其接口则是同一角色对应的接口隔离模式。

六、迪米特法则

迪米特法则：又叫做最少知识原则，它是指一个对象应当对其他对象有尽可能少的了解，不比与不相关的对象直接联系。

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

    广义：一个模块设计的好坏，一个重要标志就是该模块在多大程度上将自己的内部数据与实现的有关细节隐藏起来。

    作用：迪米特法则有利于降低类之间的耦合度。由于类与类之间去除了依赖关系，则各个软件功能模块之间相互独立。遵循迪米特法则进行系统设计时，如果系统需要扩展，则更加符合开闭原则对修改关闭的要求。使用迪米特法则将系统的内部数据与实现细节隐藏，从而使各个功能子模块远离耦合，最终达到提高代码的重用性和可维护性。

    如何实现迪米特法则：

    设计者对类进行分类设计时，需要创建低耦合的类层次关系，使得类之间的耦合度越来越低，从而达到高度重用的效果。

    设计者对类进行构造时，每个类之间都需要降低成员之间的访问程度。特别是实体类，我们需要尽量减低它的访问权限。我们可以开放取值和赋值的方法让外界间接访问自己的属性，但是我们把实体类定义成public，那么客户程序就可能会调用这个类。此时，实体类删除，则会导致一些客户程序出错。

    尽量把一些类设计成不变的类，方便功能的实现。

    注意与依赖倒换原则相结合。因为过度使用迪米特法则会产生大量的中间类，这将导致系统维护变得复杂。此时，可使用依赖倒换原则来解决，通过在调用方和被调用方之间增加一个抽象层，被调用方在遵循抽象层的前提下就可以自由变化，此时抽象层成了调用方的“朋友”。