HeadFirst设计模式读书笔记

入门介绍

---

• 鸭子应用
  父类来控制游泳与呱呱叫行为直接写具体实现，外观（display）方法抽象出来让每个鸭子自己继承后实现控制，扩展容易，需要鸭子飞的话直接让父类添加飞（fly）即可。
  ⬇ 从继承到接口 （Android的点击事件绑定就是类似形式）
  将飞（fly）从父类抽取放进接口，不需要每次都检查功能覆盖，而且能清晰的看到所有鸭子的行为区别，然而重复的代码变多，代码无法复用。

但是48个鸭子都要改飞行怎么办？

⬇ 采取良好的OO软件设计原则
找出应用中需要变化之处，把他们独立出来，不要和那些不需要变化的代码混在一起。
针对接口编程，而不是针对实现编程。

采取良好的OO软件设计原则

⬇ 从接口到封装隔离
隔离出一个鸭子行为类，去实现需要的行为接口，这样的设计，可以让动作被其它的类复用，因为这些行为和鸭子无关了。

从接口到封装隔离

⬇ 从隔离到抽象父类
将父类换成抽象类，这样的意义在于，具体的实现不会被父类绑死，实例化动作不再需要硬编码，而是在运行时指定具体实现的对象，不要关心它具体是鸭子是狗，只要让它叫就可以。

从隔离到抽象父类

⬇ 整合行为成为变量 将飞行和呱呱叫声明为接口类型的变量，不用鸭子对象不亲自处理呱呱叫的行为，而是委托给quack Behavior引用的对象，quack Behavior在运行时再通过实例化相应实现类来做出行为。

整合行为成为变量

⬇ 行为变量从静态到动态

在Duck类中添加set方法来随时改动行为变量，这样在运行时构造器实例化为不会飞的鸭子，也能动态改变为火箭动力的鸭子。

行为变量从静态到动态

⬇ 从鸭子到算法族

多用组合(composition)，少用继承

上述中的飞与呱呱叫行为的组合，使得系统具有很大的弹性，不仅封装算法族为类，还可以运行时改变行为。

策略模式(Strategy Pattern) 定义了算法族，分别封装起来，让他们之间可以相互替换，此模式让算法的变化独立于使用算法的客户。
关于UML类图的语法

从鸭子到算法族

共享模式词汇 共享模式词汇用更少的词汇做更充分的沟通，保持在设计层次，帮助建立社区。

建立可维护的OO系统，在于随时想到系统可能需要的变化和应付变化的原则。

• 可复用

• 可扩充

• 可维护

不管当初软件设计得多好，一段时间后，总是需要成长 与改变，否则软件就会“死亡”。

观察者模式（Observer Pattern）

---

松耦合，jdk使用最多的模式之一，帮你的对象知悉现况，不会错过该对象感兴趣的事。（例如报纸和杂志的订阅，即出版者（Subject）+订阅者（Obsever）=观察者模式）

• 气象监测应用
  为气象观测站建立Internet观测站，使用Weather Data对象负责追踪目前的天气状况（温度、湿度、气压），当Weather Obect对象获得最新的测量数据时，三种布告板实时更新。
  
  气象监测应用
  
  目前已知信息分析

1. 三个测量值具有getter。
2. 数据更新时，measurementsChanged方法被调用，不在乎如何被调用。
3. 三种布告板跟随数据更新。
4. 系统可以扩展，其它开发人员可以简历定制布告板，用户可以随喜好删除任何布告板。

松耦合 当两个对象松耦合，他们依然可以交互，但是不太清楚彼此的细节。

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

设计原则 为了交互对象之间的松耦合设计而努力。松耦合的设计之所以能让我们建立有弹性的OO系统，能够应对变化，是因为对象之间的互相依赖降到了最低。

进入正题，实现流程

接口的初步实现
给予主题(Subject)接口registerObserver(Observer o)和removeObserver(Observer o)方法用于注册或删除观察者(Observer)，notifyObservers()方法用于状态变化时通知所有观察者。
给予观察者(Oberver)接口update()方法，传入状态值并执行更新操作。
定义DisplayElement接口作为布告板需要显示时候的接口。

真正拥有数据的人永远只有主题，这样避免了让许多对象控制同一份数据，可以得到更加纯净的OO设计。
松耦合的威力

• 主题不需要关心观察者是谁或其它细节，只需要知道它实现了Observer接口。
• 任何时候都可以随时增加删除观察者，甚至在运行时取代现有的观察者。
• 不必为兼容新类型观察者而修改主题代码。
• 改变主题或观察者的一方也不会影响到另一方。

设计原则 为了交互对象之间的松耦合设计而努力。

设计气象站

所有的观察者抽取出，一个观察者接口和一个显示行为的接口，开发人员通过实现它来创建自己的布告板。

Observer

装饰器模式 Decorator Pattern

---

对象组合，在运行时装饰类，运行时扩展远比编译时的继承威力大。

工厂模式 Factory Pattern

---

新的对象制造方法，解决初始化耦合，摆脱复杂依赖。

单例模式 Singleton Pattern

---

创建独一无二，只能有一个实例的对象入场券，类图是最简单的，只有一个类。

命令模式 Command Pattern

---

将方法封装，运算块封装成形，调用运算的对象不用担心具体实现，比如记录日志。（貌似很常见？）

适配器模式 Adapter Pattern

---

将方块放进圆洞？让接口看起来不像是自己而是像别的东西，就可以将类的接口转换成想要的接口。（想象一下Android的RecyclerView适配器？）

Adapter

外观模式 Facade Pattern

---

与前者类似，不同的是将对象封装以简化接口。

模板模式 Template Pattern

---

封装算法块，让子类任何时候都可以将自己挂进运算里。（可以联想Django的网页模板？）

Template

迭代器模式 Iterator Pattern

---

对象堆起来的集合，让客户遍历你的对象而又无法窥视对象的存储方式。（有点像点菜只能看到菜名而不知道具体怎么做的菜？）

Iterator

状态模式 State Pattern

---

通过改变对象内部的状态帮助对象控制自己的行为。（游戏开发的角色状态机？）

代理模式 Proxy Pattern

---

白脸提供友善服务，黑脸控制访问，管理访问，代替某些懒惰的对象干活。

复合模式 Compound Pattern

---

各种威力强大的OO设计同时采用多个设计模式（大杂烩，Android的网络请求封装再加mvp）