概述
大话设计模式阅读总结
- 一、状态模式
- 二、适配器模式
- 三、备忘录模式
- 四、组合模式
- 五、迭代器模式
- 六、单例模式
- 七、桥接模式
- 八、命令模式
- 九、职责链模式
- 十、享元模式
- 十一、中介模式
- 十二、解释器模式
- 十三、访问者模式
- 十四、设计模式总结
一、状态模式
- 定义：
状态模式(State)，当一个对象内在状态改变时允许改变其行为，使这个对象看起来变成了其他类 - 优点：
2.1 将所有与某个状态有关的行为放到一个类中，并且可以方便地增加新的状态，只需要改变对象状态即可改变对象的行为。
2.2 允许状态转换逻辑与状态对象合成一体，而不是某一个巨大的条件语句块。
2.3 可以让多个环境对象共享一个状态对象，从而减少系统中对象的个数。 - 缺点：
3.1 状态模式的使用必然会增加系统类和对象的个数。
3.2 状态模式的结构与实现都较为复杂，如果使用不当将导致程序结构和代码的混乱。
3.3 状态模式对"开闭原则"的支持并不太好，对于可以切换状态的状态模式，增加新的状态类需要修改那些负责状态转换的源代码，否则无法切换到新增状态，而且修改某个状态类的行为也需修改对应类的源代码。 - 应用场景：
代码中包含大量与对象状态有关的条件语句 - 如何实现：
5.1 定义状态类接口(State)，里面有处理方法
5.2 实现接口(ConcreateState)，创建不同状态所对应的类，实现处理方法
5.3 创建一个类用于管理状态(Context)，里面定义有最初的状态并调用方法 - 代码实现：
二、适配器模式
- 定义：
将一个类的接口转换成客户所需要的另一个接口。Adapter使得原来因接口不兼容而不能一起工作的类能一起工作 - 何时使用：
想使用一个已经存在的类，但它的接口与需求不同，这时就可以考虑适配器模式。注意：最好在软件开发前期就制定统一接口规范，在后期维护时2边都不好修改时一般才使用适配器模式 - 实现方法：
3.1 定义目标接口(Target)，里面有目标方法
3.2 创建适配器类（Adapter），实现Target，里面有对被适配者（adaptee）的引用，在构造时传入被适配者，在覆写方法时通过adaptee调用被适配者中需要适配的方法
3.3 创建被适配者类，定义需要适配的方法 - 代码实现：
三、备忘录模式
- 定义：
备忘录（Memento）：在不破坏封装的前提下，捕获一个状态的内部状态，并在该对象之外保存这个状态。这样以后就可以将该对象恢复到原来的状态 - 优点：
2.1 给用户提供了一种可以恢复状态的机制，可以使用户能够比较方便地回到某个历史的状态。
2.2 实现了信息的封装，使得用户不需要关心状态的保存细节 - 缺点：
消耗资源。如果类的成员变量过多，势必会占用比较大的资源，而且每一次保存都会消耗一定的内存 - 何时使用：
4.1 需要保存/恢复数据的相关状态场景。
4.2 提供一个可回滚的操作 - 如何实现：
5.1 新建目标实体类（Originator），里面定于有创建备忘录的方法，返回值是一个备忘录对象；还需要定义读取方法
5.2 创建备忘录类（Memento），里面的属性与实体类相同，可用构造方法传参
5.3 创建管理类（CareTaker），里面有备忘录对象，用于管理备忘录 - 代码实现：
四、组合模式
- 定义：
组合模式（Composite），将对象组合成树形结构表示 ‘部分-整体’ 的层次结构。组合模式使得用户对单个对象和组合对象的使用具有一致性。 - 优点：
2.1 组合模式定义了包含基本对、组合对象的类层次结构。基本对象可以组合成更复杂的对象，而这个对象又可以被组合，这样不断递归，客户代码中任何用到基本对象的地方都可以用组合对象。
2.2 用户不用关心是根节点还是子节点，这样就不用复杂的判断语句决定调用了。
2.3 组合模式让客户可以一致的使用组合结构和单个对象。 - 缺点：
3.1 设计较复杂，客户端需要花更多时间理清类之间的层次关系；
3.2 不容易限制容器中的构件；
3.3 不容易用继承的方法来增加构件的新功能； - 何时使用：
4.1 需求中体现部分与整体层次结构时
4.2 希望用户可以忽略组合对象与单个对象的不同，统一使用组合结构中所有对象 - 如何实现：
5.1 定义抽象构件（Component）接口，里面有默认行为
5.2 定义树枝构件（Composite）类，里面应实现增减，移除叶节点的功能
5.3 定义树叶构件（Leaf）类，里面应实现相应功能 - 代码实现：
五、迭代器模式
- 定义：
迭代器模式（Iterator），提供一种方法顺序访问一个聚合对象中各种元素，而又不暴露该对象内部显示 - 使用：
由于许多语言已经把该模式用在了语言中（java中的for，foreach循环），因此只大概了解如何实现即可 - 代码实现：
六、单例模式
- 定义：
单例模式（Singleton Pattern），保证一个类只有一个实例，并提供一个访问它的全局访问点。 - 优点：
2.1 在内存中只有一个实例，减少了内存的开销，尤其是频繁的销毁和创建实例。
2.2 避免对资源的多重占用 - 缺点：
没有接口，不能继承，与单一职责原则冲突，一个类应该只关心内部逻辑，而不关心外面怎么样来实例化 - 如何实现：见下面代码=。=
- 代码实现：
七、桥接模式
- 定义：
桥接模式（Bridge），将抽象部分与他的实现部分分离，是他们都可以独立变化。 - 优点：
2.1 抽象和实现的分离。
2.2 优秀的扩展能力。
3.3 实现细节对客户透明。 - 缺点：
桥接模式的引入会增加系统的理解与设计难度，由于聚合关联关系建立在抽象层，要求开发者针对抽象进行设计与编程。 - 何时使用：
实现系统可能有多个角度分类，每一种角度都可能变化，那么就把这种多角度分离出来让他们独立变化，减少它们间的耦合。 - 代码实现：
八、命令模式
- 定义：
命令模式（Command），将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及可支持撤销操作 - 优点：
2.1 能较容易的设计一个命令队列
2.2 在需要的情况下，可以较容易地将命令写入日志
2.3 允许接收请求的一方决定是否否决请求
2.4 较容易实现撤销命令操作
2.5 新增具体命令类很容易 - 缺点：
使用命令模式可能会导致某些系统有过多的具体命令类 - 何时使用：
认为是命令的地方都可以使用命令模式 - 如何实现：
5.1 创建Reciver类，里面有实现命令的具体方法
5.2 创键Command抽象类，里面有对Reciver类的具体引用及抽象命令方法
5.3 创键ConcreateCommand类继承Command
5.4 创键Invoke类里面有对Command类的引用及撤销方法 - 代码实现：
九、职责链模式
- 定义：
职责链模式（Chain Of Responsibility），使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这个对象连成一条链，并沿该链传递请求知道请求处理为止。 - 优点：
2.1 接收者和发送者都没有对方明确的信息，且链中的对象并不知道链的结构，可简化对象相互链接。
2.2 可以随时增加或修改链的结构，增强了灵活性。 - 缺点：
3.1 不能保证每个请求一定被处理。由于一个请求没有明确的接收者，所以不能保证它一定会被处理，该请求可能一直传到链的末端都得不到处理。
3.2 对比较长的职责链，请求的处理可能涉及多个处理对象，系统性能将受到一定影响。
3.3 职责链建立的合理性要靠客户端来保证，增加了客户端的复杂性，可能会由于职责链的错误设置而导致系统出错，如可能会造成循环调用 - 何时使用：
在请求处理者不明确的情况下向多个对象中的一个提交请求 - 代码实现：
十、享元模式
- 定义：
享元模式（FlyWeight），运用共享技术有效的支持大量细粒度的对象 - 优点：
大大减少对象的创建，降低系统的内存，使效率提高 - 缺点：
提高了系统的复杂度，需要分离出外部状态和内部状态，而且外部状态具有固有化的性质，不应该随着内部状态的变化而变化，否则会造成系统的混乱 - 何时使用：
4.1 如果一个应用程序使用了大量对象，而大量对象造成了大量的存储开销
4.2 对象大多数状态可以外部状态，如果删除对象外部状态，可以用相对较少共享对象取代很多组对象 - 代码实现：
十一、中介模式
- 定义：
中介者模式（Mediator），用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显式地相互吸引，从而使耦合松散，而且可以独立改变它们间的交互。 - 优点：
2.1 Mediator的出现减少了Colleague类的耦合，使得可以独立修改Mediator和Colleague
2.2 由于把对象如何协作进行了抽象，将中介作为一个独立的概念并将其封装到对象中，这样关注的重点从对象的行为转移到了对象的交互上，更加宏观 - 缺点：
3.1 中介者模式容易在系统中误用，当系统出现”多对多“的对象处理使，不要着急使用中介者模式，要先考虑设计是否合理
3.2 由于将Colleague控制集中化，所以会使得中介者类很复杂 - 何时使用：
4.1 当对象之间存在复杂的网状结构关系而导致依赖关系混乱且难以复用时
4.2 当想创建一个运行于多个类之间的对象，又不想生成新的子类时 - 代码实现：
十二、解释器模式
- 定义：
解释器模式（interpreter），给定一个语言，定义它的文法的一种表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子 - 优点：
2.1 可扩展性比较好，灵活
2.2 增加了新的解释表达式的方式
2.3 易于实现简单文法 - 缺点：
3.1 可利用场景比较少
3.2 对于复杂的文法比较难维护 - 何时使用：
当有一个语言需要解释执行，并且你可以将该语言中的句子表示为一个抽象语法树时 - 代码实现：
十三、访问者模式
- 定义：
访问者模式（Visitor），表示一个作用于某对象结构中的各元素的操作。它可以使你在不改变各元素类的前提下定义作用与这些元素的新操作 - 优点：
2.1 增加新的操作很容易，因为访问者模式将有关行为都集中在一个访问者对象中
2.2 将数据结构和作用与其之上的操作耦合脱开，使操作集合可以自由地演化 - 缺点：
3.1 使增加新的数据结构变得困难 - 何时使用：
系统有稳定的数据结构，又有易于变化的算法 - 代码实现：
十四、设计模式总结
- 根据特点，可将设计模式分为创建型模式，结构型模式，行为型模式三大类
- 创建型模式：
创建型模式概念及意义：创建型模式隐藏了类的实例是如何被创建和放在一起的，只提供接口或抽象类给外部。创建型模式在创建了什么，谁创建的，怎么被创建的及何时创建这些方面提供了很大的灵活性；创建型模式抽象了实例化的过程。
1.1 抽象工厂模式：提供创建一系列或相关依赖对象的接口，而无需指定他们具体的类。
1.2 建造者模式：将复杂对象与它的表示分离，使得同样的构建过程可以创建不同的表示。
1.3 工厂方法模式：定义一个用与创建对象的接口，让子类决定实例化哪一个类，工厂方法模式使一个类的实例化延迟到它子类。
1.4 原型模式：用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。
1.5 单例模式：保证一个类只有一个实例，并提供一个访问它的全局点。 - 结构型模式：
2.1 适配器模式：将一个类的接口转换成客户所需要的另一个接口。适配器模式使得原本由于接口不兼容而不能一起工作的类可以一起工作。
2.2 桥接模式：将抽象部分与它的实现部分分离，使它们可以独立变化。
2.3 组合模式：将对象组合成树型结构以表示‘ 部分–整体 ’的层次结构，组合模式使得用户对单个对象和组合对象的使用具有一致性。
2.4 装饰模式：动态的给一个对象添加一些额外的职责。就增加功能来说，装饰模式想比生成子类更加灵活
2.5 享元模式：运用共享技术有效的支持大量细粒度的对象
2.6 代理模式：为其他对象提供一种代理以控制这个对象的访问 - 行为型模式：
3.1 观察者模式：定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖他的对象都得到通知并自动更新
3.2 模板方法模式：定义一个操作的算法骨架，而将一些步骤延迟到子类中，模板方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤
3.3 命令模式：将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化
3.4 状态模式：允许一个对象在其内部状态改变时改变它的行为，让对象看起来似乎改变了它的类
3.5 职责链模式：使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着该链传递请求，知道请求被处理
3.6 解释器模式：给定一个语言，定义它的一种文法表示，并定义一个解释器，这个解释器使用该表示来解释句子
3.7 中介者模式：用一个中介对象来封装一系列对象的交互。中介者使各对象不需要显示的相互引用，从而使其耦合松散，而且可以独立改变他们间的交互
3.8 访问者模式：表示作用与某对象结构中的各元素操作。它使你可以在不改变各元素的类的前提下定义作用与这些元素的新操作
3.9 策略模式：定义一系列算法，把它们一个个封装起来，并且使他们可以相互替换。本模式使得算法可独立与使用它的客户而变化
3.10 备忘录模式：在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可以恢复到原来的状态
3.11 迭代器模式：提供一个方法顺序访问一个聚合对象中的各个元素，而又不暴露该对象的内部表示
，
最后
以上就是不安小天鹅为你收集整理的大话设计模式阅读总结(16-)的全部内容，希望文章能够帮你解决大话设计模式阅读总结(16-)所遇到的程序开发问题。
如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。
本图文内容来源于网友提供，作为学习参考使用，或来自网络收集整理，版权属于原作者所有。
发表评论 取消回复