《设计模式之禅》读书笔记之C#版-行为类模式

备注：由于读的电子书版本是pdf的，影印都有些看不清楚。所有练习代码都单独放到了GitHub上方便以后查看。
https://github.com/yuhezhangyanru/DesignPatternDemoCollection

中介者模式

定义：又叫调停者模式，用一个中介对象去封装一系列对象交互，各个对象只用关心自己的业务逻辑，中介对象关心对象之间的相互作用， 使代码松耦合。

缺点：

会使得中介类变得庞大又复杂，N个对象的直接交互变成了一个对象跟多个对象的交互，对象越多，中介类越复杂。

实际应用场景：

1.MVC模式中的C，Controller就是用来协同处理model和view的。

2.房屋中介等等

什么时候使用中介者模式？

1.N个对象产生了相互的依赖关系（N>2）

2.多个对象的依赖情形尚不确定或可能发生改变的情况下，最好采用中介者模式，减少代码风险

3.产品开发过程中

命令模式

定义：高内聚的一个模式，将一个请求封装成一个对象，从而让你使用不同的请求把客户端参数化，对请求排队或者记录请求日志，可以提供命令的撤销恢复功能

该模式中的几个角色：

1.Receive接收者角色：用来执行具体命令

2.Command命令角色：
声明需要执行的命令

3.Invoker调用者角色：
接收到命令，并执行命令

模式的引用

优点：

1.降低类之间的耦合，调用者和接收者之间没有依赖关系
2.Command类方便扩展

缺点：

1.随着命令的增多，Command类可能变得庞大

责任链模式

使多个对象都有机会处理请求，避免请求的发送者和接收者间的耦合关系。将这些对象串成一条链，并沿着这条链处理这些请求，直到有对象处理它为止。

我的理解：避免出现现实逻辑中一串庞大的if,else if等等的复杂处理

模式应用：

优点：将请求和处理分开，提高系统灵活性

缺点：链比较长的时候性能一般，顺序遍历，调试也不太方便

注意事项：需要控制链节点数量

装饰模式（Decorator Pattern）

定义：像类继承对继承的一个功能补充，但又没有继承关系，主要是添加一些包装类，用来做扩展基本功能的时候使用

优缺点

优点：

1.装饰和被装饰的类可以独立发展，不会耦合

2.装饰模式是继承关系的一种替代方案，但本质上返回的结果依然是其本身。

3.可以动态的扩展一个实现类的功能

缺点：

需要控制装饰类数量，避免多层装饰导致结构复杂

什么时候使用？

1.可以在一个类需要添加一些附加功能时使用

2.需要动态的给一个类增加功能，这些功能可以再动态的撤销

3.需要为一批的兄弟类改装或增加功能时可以用

策略模式（Strategy Pattern）

定义：定义一组算法，把每个算法都封装起来，并且算法间可以相互切换

实现的基本思路：把算法各自封装到一个类去，定义一个上下文对象，用于切换和决定使用哪种算法

适配器模式（Adapter Pattern）

一些概念：什么事贫血对象（Thin Business Object）和充血对象（Rich Business Object）？

贫血对象：一个对象不存储实体以及对象间的关系

定义：也叫做包装模式，将一个类的接口包装成客户端期待的另一种接口，是的原本由于接口不匹配的两个类可以一起工作

使用场景：如在现有项目环境已有基本数据A类型，如A是个人信息，不得不引入一个外部数据类型B，B也是个人信息，但AB两类定义的接口和格式也完全不一样，现在如果想引入B结构读取其信息的话最好的办法就是引入适配器模式，定义一个新结构来讲B包装为A类型，使得A能兼容处理B的数据。

迭代器模式（Iterator Pattern）

定义：提供一种方法访问容器中的各个元素，而不暴露该对象的内部细节

主意：这个出现频率非常高！但是我们自己写的情况很少。如最常见的List接口类已经实现了迭代器，List list, list.GetEnumerator()就可以获得所有元素并遍历。但是了解这个模式还是很有帮助的，自己在写自定义容器的时候可以自己实现迭代器。

组合模式（Composite Pattern）

定义：也叫合成模式，或部分-整体模式，将对象组合成树状结构以反映部分-整体的层次结构

使用场景：

遇到树形结构时，维护树形菜单，文件夹管理。

观察者模式（Observer Pattern）

定义：也叫发布订阅模式，定义一对多一个依赖关系，使得当一个对象状态发生变化时，其他依赖对象都能被通知并自动更新。

使用场景：

1.关联行为的场景
2.事件多基触发场景
3.跨系统的消息交换，如消息队列

注意：控制模式中最多只有一个对象既是观察者也是被观察者，消息最多被转发一次

门面模式（Facade Pattern）

定义：也叫做外观模式，邀请外部访问子系统必须通过统一的一个对象来进行,除了这个接口不允许有任何单独访问子系统的行为发生

优缺点：

优点：

1.减少系统相互依赖，所有依赖通过门面对象进行，根子系统无关
2.提高系统灵活性和安全性

适用场景：

1.为复杂的子系统提供外部访问接口
2.子系统相对独立时
3.防止低水平人员扩散代码风险，怎么感觉在说我？

注意：门面对象尽量不要参与子系统的业务逻辑，而是只调用子系统的处理

备忘录模式（Memento Pattern）

定义：捕获一个对象的内部状态，并在对象外保存这个状态，以后可以将对象恢复到这个状态。类似复制对象值并保存。

使用场景：

1.需要保存和恢复数据相关的状态时
2.提供一个可回滚操作
3.需要监控的副本场景时

访问者模式（Visitor Pattern）

注意：这个模式没怎么看懂，以后需要重新看？？？

状态模式（）

定义：当一个对象内在状态改变时允许其改变行为

依然没有看懂！！！

---

解释器模式（Interpreter Pattern）

定义：给定一门语言，约定其文法表示，并给定一个解释器，使用该解释器来解释语言中的句子。实际使用较少

使用场景

• 重复发生的问题可以使用解释器模式。如数据分析工具，报表设计工具，科学计算工具等
• 一个简单语法需要解释的场景
• 需要主要注意：重要场合避免使用该模式，减小使用所来的排查和维护问题

---

享元模式（Flyweight Pattern）

定义：系统中可能直接实例出大量相似对象造成内存压力的时候使用对象共享来优化

一些定义：

• 内部状态：存储在对象内部的数据，不会随外部环境变化而改变
• 外部状态：外部对象依赖的一个标记，可以作为一批对象的统一标识，作为对象索引值使用

使用场景：

• 系统中有大量相似对象
• 对象都具有比较接近的外部状态，且内部状态跟环境无关，即对象没有特定身份
• 需要缓冲池

注意：

• 案例代码中是用string作为对象池的key了，实际如果要用对象做为key的话，需要注意对象值全相等的判定
• 如下图是我对照书上C#版本中100万次结构索引和string索引耗时对照的截图，但运行有不稳定的时候，总体上相差不会太多，不会像Java中那么夸张到string优化的不得了，所以string做索引这件事可以只是一个参考，真频繁到那个地步了，数据对象字段太多的情况下可以考虑优化。
  

- 跟缓存池还不完全一样，对象缓存池解决创建销毁消耗太大的问题，而这个模式的重点在于对象太多复用的问题，考虑哪些字段作为key来共享对象 需要多考虑

---

桥梁模式（Bridge Pattern）

定义：将抽象和实现解耦，使得两者独立的变化，简单地说，是对继承关系的补充和优化。容易变化的行为换一种方式，而不是直接继承 去实现它

使用场景

• 不希望或不适用继承的场景
• 接口或抽象类不稳定时
• 重要性比较高的场景，设计粒度越细，则被重用的可能性就越大，采用继承则受父类限制，不可能出现太细的粒度