观后总结：Head First设计模式

小灰灰 2022-02-03 14:05 219阅读 0赞

# 观后总结：Head First设计模式 #

首先，这是一本轻松的设计模式书，教你如何利用设计模式复用其他人的经验，如何利用设计模式提高代码的可维护性和可扩展性~

Head First陆续的介绍了策略模式、观察者模式、装饰者模式、工厂方法模式、抽象工厂模式、单件模式、命令模式、适配器模式、外观模式、模板方法模式、迭代器模式、组合模式、状态模式、代理模式，在介绍各种模式的期间，用简单的应用场景、通俗的语言引导读者去思考这些模式是如何利用和遵循相应OO原则的，然后再清晰的总结出每种模式的定义。

下面我再一一地总结一下学习到的每种设计模式。

## 1. 策略模式 ##

**问题/场景：**  
比如对于发消息的场景，系统消息、push消息的都遵循同样一组行为：行为A 校验消息内容无误，B 存储消息，C 校验是否超出发送限制，D 发送消息，假如两种消息的消息内容一致，所以两种方法的校验规则和存储方式一致，也就是行为A B是一样的，但是二者的发送限制不一致，也就是C，D行为不一致

**解决方案：**

*  我们很自然想到，定义一个消息发送的类，有4个方法，分别是校验消息，存储消息，校验发送限制，发送消息，系统消息和push消息都继承这个类，与父类方法C D不一致的，覆盖父类的方法。问题来了，现在我需要再加一种短信息发送，短信息的消息内容与系统消息、push消息不一致（需要覆盖A B方法），但是校验发送限制的方法和push消息一致（且父类方法中的C方法正好是系统消息的检验规则，所以也需要覆盖C方法），需要覆盖的内容好多，且存在重复代码。
 *  上面的解决方法比较麻烦，根据OO原则——封装变化，我们可以讲变化的行为封装起来，由子类发送系统消息、发送push消息、发送短信息决定使用哪一种行为。

**定义：**  
策略模式定义了算法族，分别封装起来让他们之间可以互相替换，此模式让算法的变化独立于使用算法的客户。

**结构：**  
接口实现方式：  
![接口实现][SouthEast]  
策略模式方法：  
![策略模式方法][SouthEast 1]

**其他：**  
我们会考虑发送消息的过程是校验消息内容、存储消息内容、校验发送限制、发送消息，当我们意识到这些行为可能会修改或扩展的时候，我们可以转换一下思考方式，发送消息的过程有4个行为，校验消息内容……  
在设计代码的时候提前想到需要变化的部分，封装起来，日后的扩展便会简单一些~

**要点总结：**  
\- 封装变化  
\- 多用组合，少用继承  
\- 针对接口编程，不针对实现编程

## 2. 观察者模式 ##

**问题/场景：**  
观察者模式的应用场景比较多，当目标状态发生改变的时候，需要通知多个依赖者，这种情况都可以使用观察者模式。比如对于某种套餐的订单，一个套餐订单（订单系统维护）包括会员身份（部门a维护）、邀约资源（部门b维护）、精品职位数（部门c维护）……当订单的状态改变的时候，我们需要部门a b c都做出相应的响应，处理各自维护的订单资源。

**解决方案：**  
订单系统是真正拥有订单状态数据的对象——主题，部门a b c都是主题的依赖者，需要使用订单状态这同一个数据——观察者。  
可能我们想到的方案是由主题提供查询订单状态的接口，观察者各自查询订单状态，这样每个观察者在查询的时候确实都能拿到订单状态，但是可能会导致两个问题，首先，观察者查询的时间是不确定的，也就是订单状态更新的时候，所有观察者并不能实时更新信息，直到自己主动去查询；其次当查询状态的接口变化的时候，需要所有的观察者各自作相应的修改，主题和观察者之间有很强的耦合。如果是订单状态改变的时候，主题发布一个通知，所有观察者监听这个消息。  
订单系统需要实现主题接口，部门a b c分别注册为订单系统该主题的观察者，订单状态改变时，观察者都会收到订单系统发出的消息。

**定义：**  
观察者模式定义了对象之间的一对多依赖，这样一来，当一个对象改变状态时，它的所有依赖者都会收到通知并自动更新。

**结构：**  
![观察者模式][SouthEast 2]

**其他：**  
我们这里忽略观察者模式和发布订阅模式的差别，观察者模式是有主题对象自己调度和发布通知，而发布订阅模式是有调度中心统一调度。  
考虑到主题与观察者之间需要松耦合，方便观察者的扩展与删除，也方便主题房的修改冰箱观察者，我们可以采用观察者模式。

**要点总结：**  
\- 观察者模式定义了对象之间一对多的关系。  
\- 观察者与可观察者之间用松耦合的方式洁儿，互不知道对方的实现细节。

## 3. 装饰者模式 ##

**问题/场景：**  
估计我们平时接触到的最多的装饰者模式就是Java的IO类。在不修改FileInputStream这个基本的字节读取类的同时，增加新的功能利用缓冲来改变性能，那么我们就可以使用装饰着模式，利用BufferedInputStream这个装饰者类增加缓冲输入和readline()的功能。

**解决方案：**  
按照上面的例子，BufferedInputStream扩展自FilterInputStream这个抽象的装饰类，BufferedInputStream拥有FileInputStream这个基础组件的行为，并且增加扩展的装饰者的行为。

**定义：**  
装饰者模式动态地将责任附加到对象上，想要扩展功能，装饰者提供有别于继承的另一种选择。

**结构：**  
IO类装饰者模式示例示意图  
![IO类装饰者模式示意图][IO]  
![装饰者模式][SouthEast 3]

**其他：**  
装饰者会导致设计中出现很多的小对象，会让程序变得稍微复杂，但是对于一些动态扩展行为的场景来说，装饰者是很方便和易扩展的。  
当我们在考虑需要扩展一个基本功能的组件时，我们可以考虑使用装饰者模式增强代码的弹性、可扩展性。

**要点总结：**  
\- 装饰者模式的原则是我们最常见的开闭原则。  
\- 使用组合和委托的方式，可以在运行时动态地加上新的行为。

## 4. 工厂方法模式 ##

**问题/场景：**  
我们经常会有使用下面这种代码的场景：

Pizza pizza = null;
    if（type == 1）{
        pizza = new CheesePizza();
    }else if(type == 2){
        pizza = new GreekPizza();
    }else if ……

我们创建Pizza对象的时候可能都需要用到这段代码。

**解决方案：**  
考虑到用到这段创建Pizza对象的地方可能会比较多，而且Pizza的种类可能需要增减，更好一点的方式，我们可能将这段放到一个专职创建Pizza对象的新对象中——“工厂”。  
简单工厂我们可能会经常使用到。

public class PizzaFactory（）{
        Public Pizza createPizza(int type){
            Pizza pizza = null;
            if（type == 1）{
                pizza = new CheesePizza();
            }else if(type == 2){
                pizza = new GreekPizza();
            }else if ……
    
            return Pizza;
        }
    }

但是如果我们的场景进行扩充，最终创建出来的pizza，不仅依赖type——pizza种类，还需要依赖不同制造工艺style（比如芝加哥风格的，纽约风格的……）。那我们需要扩展PizzaFactory类，以满足创建pizza对象的需求，PizzaFactory的依赖的具体Pizza种类越来越多了。  
为了减少依赖，我们将创建Pizza的方法作为一个抽象的方法factoryMethod，具体不同工艺的工厂来实现这个factoryMethod。  
相对于前面的简单工厂的模式，当我们扩展一种加州风格的pizza时，不需要修改工厂方法，只需要增加一种工艺的工厂。（工厂与具体要创建的产品解耦）。  
**定义**  
工厂方法模式定义了一个创建对象的接口，但由子类决定要实例化的类是哪一个。工厂方法让类把实例化推迟到子类。

**结构**  
![工厂方法模式][SouthEast 4]

**要点总结**  
工厂方法模式用到了依赖倒置原则——要依赖抽象，不要依赖具体类。（比如这里pizza工厂依赖的是Pizza抽象，具体的CheesePizza等也依赖Pizza抽象，即高层和底层模块都依赖Pizza这个抽象）

## 5. 抽象工厂模式 ##

**问题/场景：**  
继续扩展上面的场景，如果我们在PizzaFactory中创建CheesePizza的时候，需要考虑原料的不同，比如纽约风味的pizza都需要使用原料组合a（大蒜番茄酱料、干酪），而芝加哥需要使用另一种原料组合b（意大利白干酪和比萨草）。那么我们在createPizza创建对象的时候还需要把原料工厂传递过去。

**解决方案：**  
CheesePizza类的构造方法换成CheesePizza(原料工厂抽象类)，计提的所有原料怎么组合怎么选择，全部由具体的原料工厂决定。  
原料工厂的接口如下：

public interface PizzaIngredientFactory{
        public Sauce CreateSauce();//酱料
        public Cheese CreateCheese();//芝士
        ……
    }

具体的原料工厂决定具体的原料。

**定义**  
抽象工厂模式提供一个接口，用于创建相关或依赖对象的家族，而不需要只能具体类。

**结构：**  
![抽象工厂模式][SouthEast 5]

**其他：**  
抽象工厂模式看起来和工厂方法模式很类似，都是负责创建对象，但是不同在于抽象工厂模式利用对象的组合，本身定义了产品的创建方法，必须要实现这些方法来完成产品家族的创建；而工厂方法利用的是继承，通过继承来覆盖工厂方法，完成产品的创建。

**要点总结：**  
\- 工厂都是用来封装对象的创建。  
\- 工厂方法模式使用继承，抽象工厂使用对象组合；两者利用抽象的原则，将具体的实例化过程延迟到子类。  
\- 工厂利用的最重要和基本的原则——依赖抽象，不要依赖具体类。

*TODO 其他模式的介绍&&模式归类与比较后续添加*  
参考书籍：《Head First 设计模式》

[SouthEast]: /images/20220203/adc72393859241d4b38683f9840db830.png
[SouthEast 1]: /images/20220203/e115c0e6c1894ebf84ba87af727dd11a.png
[SouthEast 2]: /images/20220203/3edb0ac1fd1b468286aac32aefe7b88f.png
[IO]: /images/20220203/319ebcfaea544ac0a3ceb91009e1adfe.png
[SouthEast 3]: /images/20220203/c5d053cbdcac4f4893ae64e9d9a6f157.png
[SouthEast 4]: /images/20220203/838c0a6b018c404bbff880d417236fa5.png
[SouthEast 5]: /images/20220203/ea5eef4d24b0477baaedec1ab0985cfc.png