《软件设计模式读后总结》

总述

软件设计模式算是软件从业人员的教科书级参考书籍，我在上大学的时候大致的看过一遍（大学~你懂的~），鉴于水平有限，有很多不明白理解的地方。正好今年毕业以后有幸在一家公司供职并开始从事软件产品的开发工作，开始接触真正的产品开发。重新拿起本书，读过以后有了有别于上次的阅读的理解和感受，也存在的还是不理解的地方。这次在博客中写出自己的理解，也算是看过以后的总结，向大家讨教，共同学习。

正文

本书一共介绍了常用的设计模式，描述了各个设计模式的设计原因和解决方案，并通过简单案例描述和Java代码实现的方式加深理解。我先在此列出以上设计模式的描述与理解，有理解偏差的地方请指出。

Command Pattern 命令模式

命令模式解决了对象间调用又希望减少对象间耦合的问题。通过将对象调用请求封装的方式使请求者和被请求者相互隔离，即请求者对象调用包含了被请求者对象引用的“命令”对象，实现方法的调用与耦合的减少。该模式在产品开发中非常的常见，比如一些服务器API的网络请求封装在“网络请求命令对象”中，在Client或者Brower端通过调用该命令对象的暴露方法进行网络请求而不需要知道网络请求的具体过程，减少调用对象间的彼此耦合。

Observer Pattern 观察者模式

观察者模式解决了对象数据变动与对象间交互的问题，使对象中的数据变动能够实时的发送消息给其他对象，实现对象间数据变动的实时交互。在被观察者对象中添加观察者对象的引用，当被观察者对象中的敏感数据变动时，调用自身的更新方法，遍历观察者对象表，逐一的调用观察者对象中的更新行为，实现对象间的数据敏感和交互。注意，在方案实现中，往往观察者和被观察者对象中都包含着对方的对象应用，在不同的编程语言中，需要注意对象内存关联问题，之所以在观察者中有被观察者对象引用，是为了便于观察者调用被观察者中的函数行为将自身索引加入到被观察者的观察者列表中。在iOS中，我认为Notification的使用就是一个非常典型的观察者模式的运用，通过该方案的使用，UI可以较实时的反应服务器数据的变动。另外，数据敏感的具体实现上有推数据和拉数据的区别，这就看在数据变动后被观察者使用观察者对象的方式，是直接将变动数据以参数形式传递给被观察者还是暴露数据更新借口供观察者使用。

Decorator Pattern 装饰模式

装饰模式解决了不希望通过继承方式扩展类方法的问题，通过保存被修饰者的引用，在调用被修饰者原有的函数行为之上加上自身修饰者的函数逻辑，实现保留类方法基础上扩展类，并在不同的情况下调用不同的“同名”函数。相比于传统的继承模式，使用装饰模式可以最大程度的保护的被修饰者自身，便于系统的扩展和维护 。联想Java的IO中Reader,Buffer，是使用了装饰模式来特定扩展Reader, Buffer的功能。

Strategy Pattern 策略模式

策略模式解决了算法不同变体统一的问题，通过接口定义，使继承出的对象能根据不同的要求适应不同的算法变体，避免对象中使用过多的判断语句而形成代码冗余。我在产品开发中，曾经就遇到一个问题。在UI处理中，经常要根据一张图去动态生成不同尺寸的UI图，这时我就用策略模式封装了生成模块，根据图的类型和需求尺寸动态生成不同的图片。

Adapter Pattern 适配器模式

适配器模式解决了接口不匹配对象间无法关联使用的问题，使用时声明接口变量，将适配器赋给接口，使适配器初始化时包含被适配接口，从而时不匹配的接口能符合程序、客户的接口要求并且不更改原有接口实现，而且和命令模式一样，适配和被适配接口对象间是松耦合关系，符合软件开发的要求。

Chain Of Responesibility Pattern 责任链模式

责任链模式解决了多个对象处理对象流的问题，使处理事物的对象模块彼此连接，让需要处理的对象在此对象上行进，直到有一个事务处理模块处理了该对象为止。每个子事务处理模块接收到事务处理对象时，通过特定要求选择处理或者将模块传递给下一个模块。联想Android和iOS中的触摸事件的传递，触摸事件对象在各图层间依照一定的顺序传递直到在一个图层中被接收处理或者在最上层抛出停止。

Facade Pattern 外观模式

外观模式其实就是讲一系列功能整合成一个成型的模块或者系统，并提供标准化的接口对象供外部使用其子功能的成熟模式。

Iterator Pattern 迭代器模式

 迭代器模式是用来获得数据集中逐个数据而不需要李阿胶数据集存储结构的设计模式。在现今编程语言中，基本都有迭代器的概念（PS：int i = 0;i < x; ++i，那i原来是这么来的说）。基于产品的需求，可以使用多种存储结构复用，自定义的迭代器就可以很好的解决数据集内的数据遍历获取操作行为。

Mediater Patten 中介者模式

中介者模式解决了对象间相互交互但不需要相互引用的问题，使对象间耦合度变小。当将一系列对象的交互集中在一个中介者类中时，每个对象都只有中介者对象的引用，切中介者对象管理着对象间交互的实际操作。便于系统的维护和二次开发，但是因为集中了大量的对象交互，可能会使中介者对象非常复杂，又加大了中介者类的维护难度。

Factory Method Pattern 工厂方法模式

工厂方法模式解决了特殊要求实例化对象的问题，通过接口的方式，让实现接口的类自定义实例化的方式。在接口中定义实例化方法，接口的子类实现该接口并自定义创建的对象类型，并封装实例化的逻辑代码，让用户只关注与对象的暴露接口的使用而无需在意对象的实例化。

Builder Pattern 生成器模式

生成器模式解决了包含众多对象引用变量的对象依照不同需求实例化不同的问题。将该对象的实例化过程封装在另一个生成器对象中，生成器对象含有多种自定义的不同实例化方法。该模式使系统给用户提供内部较复杂的对象时更加便利，简单，使用户专注于对象的使用而非实例化。