众多的设计模式

看着这些设计模式，但是发现这些设计模式有优点也有缺点。 优点就是带来了 可维护性、可扩展性、可复用性、较好的灵活性。 但同时带来编码工作量变的复杂、偶尔也会降低可维护性，比如装饰器模式：多层的装饰比较复杂，当使用多层装饰出现问题时，排查问题的工作量比较大；比如享元模式：提高了系统复杂性，需要分离出内部和外部状态。 在具体使用过程中，还是要仔细考虑之后再决定是否使用当前的场景。<模式乱用不如不用>

代理模式（结构型模式）

用的较少，被代理的实例化类在书中样例是写死的，实际编码过程中应该可以通过反射去实现 同一种类别不同 实现细节的子类。从而达到更好的扩展性和维护性。

外观模式（结构型模式）

经常使用，但是不知道是外观模式的模式。外观模式主要利用了关联关系来进行解耦或复用。

观察者模式（行为模式）

C#中实现了委托来 从而可以简化使用 观察者模式， 就是多播委托的方式。 在实际复杂的项目中，还要增加考虑观察者是否收到消息的等等确认机制。

状态模式（行为模式）

注意

一个方法里面有很多分支判断，这也意味着它的责任过大了。面向对象设计其实就是希望做到代码的责任分解。必须时刻牢记 “单一职责原则“。

定义

状态模式，当一个对象的内在状态改变时允许改变其行为，这个对象看起来像是改变了其类。
状态模式主要解决的是当控制一个对象状态转换的条件表达式过于复杂时的情况。把状态的判断逻辑转移到表示不同状态的一系列当中，可以把复杂的判断逻辑简化。当然，如果这个状态判断很简单，那就没必要用 ”状态模式“ 了。

状态模式能解决反射不能解决的问题，即大量分支and要求范围性创建子类。

适配器模式（行为模式）

> 定义

将一个类的接口转换客户希望的另外一个接口，Adapter模式使得原本由于接口不兼容儿不能一起工作的那些类可以一起工作。也是经常干的事。

比如数据库中的DataAdapter 。

适配器模式与代理模式区别

1. 适配器模式中， 翻译者与被翻译者只需要 翻译者 实现 抽象类， 被翻译者不需要实现抽象类。
2. 代理模式中， 代理者与被代理者 都需要实现抽象类。

适配器模式结构如下：

• 图中 Target表示抽象接口

迭代器模式（行为模式）

假设存在一个数组，其遍历模式可能采用依据索引来进行遍历的方法；又假设存在一个HashTable，其遍历模式可能是按照键值来进行遍历。无论是哪个集合，如果它们的遍历没有一个公共的接口，那么客户端在进行调用的时候，相当于是对具体类型进行了编码。这样一来，当需求发生变化时，就必须修改我们的代码。并且，由于客户端代码过多地关注了集合内部的实现，代码的可移植性就会变得很差，这直接违反了面向对象中的开闭原则。于是，迭代器模式就诞生了。