设计模式（一）

1 设计模式概念

        所谓设计模式，就是对经常出现的软件设计问题的成熟解决方案。实际上设计模式仅仅是对特定问题的一种惯性思维。

2 设计模式目的

        编写软件的过程中，程序员面临着来自耦合性、内聚性以及可维护性、可扩展性、重用性、灵活性等多方面的挑战，设计模式是为了让程序拥有更好的：

• 代码可重用性。相同功能的代码，不用多次编写；

• 可读性。便于其他程序员的阅读和理解；

• 可扩展性。当需要增加新功能时，非常方便；

• 可靠性。当增加新的功能后，对原来的功能没有影响；

• 使程序呈现高内聚、低耦合的特点。

3 设计模式原则

3.1 单一职责原则

        一个类，应该仅有一个引起他变化的原因。

        如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力，这种耦合会导致脆弱的设计，当发生变化时，设计会遭到意想不到的破坏。软件设计就是发现职责并把那些相互分离，如果多余一个动机改变一个类，那么这个类就具有多余一个的职责，就应该考虑类职责分离。

        优点：降低类和类的耦合，提高可读性，增加可维护性和可拓展性，降低可变性的风险。（易维护、易扩展、易复用、灵活多样）

3.2 开放封闭原则

        软件实体（类、模块、函数等等）应该可以扩展，但是不可以修改，对于扩展是开放的，对于更改是封闭的。

        设计使得面对需求的更改却可以保持相对稳定，从而使得系统可以在第一个版本后不断地推出新的版本。开放封闭原则需要：在设计时，考虑尽量使这个类足够好，写完后不用修改，需要新的需求的话，只需要增加一些类就行了。无论模块多么的封闭，都会存在存在一些无法对之封闭的变化，既然无法封闭，那么设计人员必须对于他设计的模块应该对哪些变化封闭做出选择。他必须先猜测最有可能的发生的变化种类，然后构造抽象来隔离那些变化。变化一旦发生立马采取行动，创建抽象类隔离以后发生的同类变化。

        优点：开放封闭原则是面向对象设计的核心所在，遵循该原则可以带来可维护，可扩展，可复用以及灵活性好的巨大好处，开发人员应该仅对程序中呈现出频繁变化的那些部分做出抽象，然而并不是所有的部分都需要进行抽象，放弃不成熟的抽象也十分重要。

3.3 依赖倒转原则

        抽象不应该依赖细节，细节应该依赖于抽象，即针对接口编程而非针对实现编程。除此之外，高层模块不应该依赖于低层模块，两个都应该依赖抽象。

        为什么高层模块不应该依赖低层模块？如果是依赖的话，进行新项目时，发现业务模块的高层模块相同，但采用不同的低层模块，而高层模块却和低层模块绑定在一起，就导致无法复用低层模块。如，实现某一业务，需要访问数据库，访问数据库的代码写成函数，每次执行新项目的时候调用这些数据库函数模块，这就相当于高层模块依赖于低层模块，一旦使用新的数据库，就因为高层模块与低层模块绑定在一起，导致高层模块无法复用。

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

3.4 里氏替换原则

        一个软件实体如果使用的是父类的话，那么一定适用于其子类，而且它察觉不出父类对象和子类对象的区别，软件中，把父类替换成子类程序行为无变化。（子类必须能够替换父类）

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

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

3.5 接口隔离原则

        使用多个隔离的接口，比使用单个接口要好。还是一个降低类之间的耦合度的意思，从这儿我们看出，其实设计模式就是一个软件的设计思想，从大型软件架构出发，为了升级 和维护方便。所以上文中多次出现：降低依赖，降低耦合。 （例如：支付类的接口和订单类的接口，需要把这俩个类别的接口变成俩个隔离的接口）

3.6 迪米特法则

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

        迪米特法则强调的前提是在类的结构设计上，每一个类都应该尽量降低成员访问权限。

        迪米特法则根本思想是强调类之间的松耦合。类之间的耦合越弱越容易复用，一个处在弱耦合的类被修改，不会对有关系的类造成波及。

参考文献：《大话设计模式》