设计模式和模式设计原则

设计模式

设计模式是什么？
其实写代码并不是简单的coding而已，同样的一个功能有的人能写得跟一坨屎一样，但好的程序员就能把它实现得非常优雅巧妙，还特别容易移植扩展。虽说千人千面，每个人的代码风格都不一样，但是高质量的代码总是有套路可循。在哪种典型情况下代码怎么写比较好，我想这就是设计模式定义的范畴。

首先看一个例子：

这几种写法都能实现多态，但是显然把base的指针放在Subject类之中这种写法，两个类的捆绑关系更加松散，这种方式可发挥的余地也是最大的。

模式设计原则

天下武功，要想学好，都离不开内功心法，否则招式比划得再花哨也打不到点子上，轻飘飘命中不了要害，而模式设计的原则就是设计模式的内功心法。只有真正掌握了这些原则，遇到各种各样的需求才能随进应变。

依赖倒置原则

• 高层模块不应该依赖低层模块，二者都应该依赖抽象；
• 抽象不应该依赖具体实现， 具体实现应该依赖于抽象；

举个栗子，比如你现在有一套自动驾驶系统，需要去支持本田、丰田、宝马的车（说不定以后还会扩展更多）。那么自动驾驶系统是高层，汽车生产厂商是低层，二者不应该相互依赖，一方变动另一方也会变动；而是应该抽象一个自动驾驶行业标准，高层低层都依赖它。这样就解耦了两方的变动；自动驾驶系统、汽车生产厂商都是具体实现，它们应该都依赖自动驾驶行业标准（抽象）；

开放封闭原则

• 一个类应该对扩展开放，对修改关闭。

面向接口编程

• 不将变量类型声明为某个特定的具体类，而是声明为某个接口。
• 客户程序无需获知对象的具体类型，只需要知道对象所具有的接口。
• 减少系统中各部分的依赖关系，从而实现”高内聚、松耦合“的类型设计方案。

封装变化点

• 将稳定点和变化点分离，扩展修改变化点；让稳定点与变化点的实现层次分离。

单一职责原则

• 一个类应该仅有一个引起它变化的原因。

里式替换原则

• 子类型必须能够替换掉它的父类型；主要出现在子类覆盖父类实现，原来使用父类型的程序可能出现错误；覆盖了父类方法却没有实现父类方法的职责。

接口隔离原则

• 不应该强迫客户依赖于他们不用的方法；
• 一般用于处理一个类拥有比较多的接口，而这些接口涉及到很多职责。

对象组合优于类继承

• 继承耦合度高，组合耦合度低。

什么情况下使用设计模式？

1. 系统的关键依赖点；
2. 能明确找到变化点；
3. 能明确找到复用方向；
4. 对需求变化方向熟悉；