设计模式总结

1.为什么使用设计模式

在了解设计模式之前，我们需要进行一次苏格拉底式的追问以了解我们使用设计模式的最终目的。

• 为什么要使用设计模式？为了代码可重用，容易被他人理解，保证代码可靠性。
• 为什么代码要可重用且需要容易被他人理解？因为代码需要被维护。
• 为什么代码需要被维护？因为需求总是变化和增加的。
• 为什么需求总是变化和增加的？因为编程是以迭代的方式向前优化的。

所以我理解使用设计模式的目的有三：

• 目标一：代码在拓展和变更时不要太恐怖。
• 目标二：保证代码可靠性，毕竟设计模式千锤百炼。
• 目标三：降低沟通成本，共同的设计语言。

2.六大原则

为了实现目标，人们总结出了六大原则。

• 单一职责原则：可以简单理解为每个类和每一个方法都只负责一个任务，或者说功能
  • 好处是修改这些代码时，不会出现牵一发而动全身的问题，而且容易使用单元测试。
• 开放封闭原则：可以理解为代码写好了最好不要再去修改，但是要提供拓展的方式。
• 依赖倒置原则：可以理解为把依赖项以接口或者抽象类实现，这样在依赖项被更改时，就不用大量的修改代码。
• 迪米特原则：可以理解类的直接依赖越少越好，如果非必须，可以间接调用，降低耦合。
  • 举个例子：总公司对子公司的员工类的操作就可以是通过子公司类来操作，而不是在总公司类内直接对子公司的员工类操作，这样在员工类发生变化时，只需要更改子公司类。
• 里氏替换原则：可以理解为子类可以拓展父类，但是不能修改父类原有功能，或者修改后不能影响原有的功能。
• 接口隔离原则：可以理解为不同的功能不要设计在同一个接口，因为接口时一定要被实现的，如果不相关的接口内容太多，导致后续实现该接口的类药实现一大堆无用的方法。

3.设计模式总结

创建型：一般在创建实例事使用

设计模式	说明	作用	例子和说明
建造者模式	把构建复杂对象的代码于实现隔离开	解耦，固定创建过程
简单工厂	统一接口创建不同的实例（但有共同的方法或者属性）	解耦，分离实例化过程和客户端调用	当创建很多个实现同一接口或者继承同一类时使用
工厂方法	统一接口创建不同的实例（但有共同的方法或者属性）	解耦，分离实例化过程和客户端调用	和简单工厂一致，和简单工厂的区别是，让子类决定实例化哪个类，易于拓展，简单工厂如果不用反射，就只能添加if。。。else或者switch判断了。
抽象工厂	创建一系列相关的产品	解耦，方便替换和拓展。	如数据库使用sql server，创建一系列增删改查，替换成mysql也是创建一系列增删改查
原型模式	使用clone替代直接实例化	降低开销
单例模式	全局唯一实例	降低开销和保持单一实例调用	如全局的缓存对象，不需要每次都实例化

结构型

设计模式	说明	作用	例子和说明
适配器模式	统一接口	统一接口
桥接模式	使用聚合和关联替代继承	解耦
组合模式	构建一个树形结构使得部分和整体具备一致的操作	解耦和统一操作	菜单和菜单的操作
装饰器模式	可以动态的添加额外的职责	解耦，更容易拓展额外功能
外观模式	构建一个高层接口，简化复杂系统	解耦，屏蔽复杂的接口使得子系统更容易使用	由一个复杂接口的子系统时
享元模式	共享部分内容二不用每次都创建	降低开销	感觉跟原型模式有点像，但是这个模式不是用来创建实例的，而是用来保存已有实例，在已经有的情况下不再去新增实例。
代理模式	通过代理去操作另外一个类	解耦，可以在代理中做一些额外操作，如权限验证和日志记录	权限验证和日志记录

行为型

设计模式	说明	作用	例子和说明
观察者模式	当被观察者发生变化时，通知一系列观察者	解耦，和观察者可以被方便的拓展	触发通知
模板方法	父类定义一个算法骨架，子类实现具体算法	固定算法的执行顺序
命令模式	将命令和执行分开	解耦，可以实现队列，日志，支持撤销
状态模式	根据状态执行不同的操作类	解耦，操作类容易拓展
职责链模式	串联起一系列操作类，直到有类别执行	解耦，操作类容易拓展	和状态模式有点类似，但是状态模式是根据状态，而职责链则不一定
解释器模式	通过解释器解释自定义的文法		正则表达式
中介者模式	通过中介者来调用其他类	解耦
访问者模式	通过分派技术	解耦
备忘录模式	记录之前的数据	可以实现撤回	游戏中的存档
策略模式	初始化时传入具体的操作策略	解耦，类似依赖注入

以上是我学习设计模式写的总结，如果错误，多多指正！