第二十九章 OOTV杯超级模式大赛-模式总结(读书笔记)-CSDN博客

本文链接：https://blog.csdn.net/Last_Impression/article/details/8274423

第29章OOTV杯超级模式大赛-模式总结

29.1 演讲任务
小菜睡眼朦胧，趴到了桌上，打起盹来，不一会儿就进入了梦乡。

29.2 报名参赛
工厂模式三姐妹：工厂方法，抽象工厂方法，简单工厂方法。简单工厂方法不符合开放封闭原则。所以在预选赛上被淘汰了。简单工厂模式的缺点就是在对每一次修改的时候都要更改工厂类，这就是对修改开放了。

29.3 超模大赛开幕式
开幕式到场来宾：抽象先生，封装先生，继承女士，多态女士。
本次大赛的评委：单一职责先生，开放封闭先生，依赖倒转先生，里氏代换女士，合成局和复用女士，迪米特先生。
结构化编程确实是有些老了，时代不同了，老的偶象要渐渐退出，新的偶像再站起来。现在是面向对象的时代。OO理念已经被越来越多的人认同。对象对象的开发者，把需求理解成一个一个的对象，让这些对象互相调用，符合了业务需要。
本次大赛根据模式的特点，设置了三个类别，分别是创建性模式，结构型模式和行为型模式。

29.4 创建型模式比赛
1号选手：抽象工厂小姐，她的口号是提供一个创建一系列或相关依赖对象的借口，而无需指定他们具体的类。抽象工厂可以解决多个类型产品的创建问题，就Hibernate而言，同一个对象与多个数据库ORM就是通过她来实现的。但是抽象工厂形象不好，太臃肿，身上类这么多，做起事来一定不够利索。

2号选手：建造者小姐，她的口号是将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。而建造者小姐把建造过程隐藏，一个请求，完整产品就创建，在高内聚的前提下使得与外界的耦合大大降低。建造者的缺点就是没有多少产品会有相同的构造。在建造者模式中，它是将一个复杂对象的构建于它的表示分离，这就可以很容易地改变一个产品的内部表示，并且使得构造代码和表示代码分开。只要告诉建造者模式需要什么，它就能用同样的构建过程创建不同的产品给客户。

3号选手：工厂小姐，她声称定义一个用于创建对象的接口，让子类决定实例化哪一个类，工厂模式使一个类的实例化延迟到其子类。从new的角度讲，工厂方法才是最棒的设计，它可是把工厂职责都分了类了，其他几位不过是她的变体罢了。工厂模式小姐的优势：通常设计都应从工厂方法开始，当设计者发现需要更大的灵活性时，设计便会向其他创建型模式演化。当设计者在设计标准之间进行权衡的时候，了解多个创建型模式可以给设计者更多的选择余地。工厂方法的实现并不能减少工作量，但是它能够在必须处理新情况时，避免使已经很复杂的代码更加复杂。

4号选手：用原型实例制定创建对象的种类，并且通过拷贝这些原型创建新的对象。原型模式可以很好的解决数据接口的复制问题。

5号选手：单例小姐，她提倡简洁就是美，保证一个类仅有一个实例，并提供一个访问它的全局访问点。单例小姐的优势就是让类自身负责保存它的唯一实例。这个类可以保证没有其他实例可以被创建，而且对唯一实例可以严格地控制客户怎样以及何时访问它。

创建型模式隐藏了这些类的实例是如何被创建和放在一起，整个系统关于这些对象所知道的是由抽象类所定义的接口。这样，创建型模式在创建了什么，谁创建它，它是怎么被创建的，以及何时创建这些方面提供了很大的灵活性。

29.5 结构型模式比赛
6号选手：适配器小姐，她的口号是将一个类的接口转换成客户系统的另外一个接口。适配器模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。适配器小姐，想使用一个已经存在的类，而它的接口不符合要求，或者希望创建一个可以复用的类，该类可以与其他不相关的类或不可预见的类协同工作。让接口不同的类通过适配后，协同工作。

7号选手：桥接模式，桥接小姐提倡的是将抽象部分与它的实现部分分离，使他们都可以独立地变化。桥接小姐很漂亮，那种解耦的方式，用聚合来代替继承，实在是非常巧妙。她主张"找出变化并封装之"。解耦这些不同方向的变化，通过对象组合的方式，把两个角色之间的继承关系改为了组合的关系，从而使这两者可以应对各自独立的变化。

8号选手：组合小姐，将对象组合成树形结构以表示"部分-整体"的层次结构，组合模式使得用户对单个对象和组合对象的使用具有一致性。组合模式的效果就是客户可以一致地使用组合结构和单个对象/任何用到基本对象的地方都可以使用组合对象。

9号选手：装饰小姐，就是动态地给一个对象添加一些额外的职责。就增加功能来说，装饰模式相比生成子类更加灵活。装饰也非常美丽，因为她善于打扮自己。

10号选手：外观小姐，她说为子系统中的一组接口提供一个一致的界面，外观模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。类之间的耦合越弱，越有利于复用，一个处在弱耦合的类被修改，不会对有关系的类造成波及。如果两个类不必彼此直接通信，那么就不要让这两个类发生直接的相互作用。如果实在需要调用，可以通过第三者来转发调用。外观模式就是应该让一个软件中的子系统间的通信和相互依赖关系达到最小，而具体办法就是引入一个外观对象，它为子系统间提供一个单一而简单的屏障。通常企业软件的三层或N层架构，层与层之间地分离其实就是外观模式的体现。外观小姐是定义一个新的接口，而适配器则是复用一个原有的接口。适配器是用来适配对象的，而外观则是用来适配整个子系统的。

11号选手：享元小姐，她的参赛宣言为运用共享技术有效地支持大量细粒度的对象。对象使得内存占用过多，而且如果都是大量重复的对象，那就是资源的极大浪费。比如文档处理软件中，当中的字符都可以是对象，而如果让文档中的每一个字符都是一个字符对象的话，这就会产生难以接受的运行开销，显然这是不合理也是没有必要的。

12号选手：代理小姐，她声称为其他对象提供一种代理以控制对这个对象的访问。代理这个小妮子，听说她甚至有可能就不是自己来参加比赛，而是找了一替身。代理与外观的主要区别在于，代理对象代表一个单一对象而外观对象代表一个子系统；代理的客户对象无法直接访问目标对象，由代理提供对单独的目标对象的访问控制，而外观的客户对象可以直接访问子系统中的各个对象，但通常由外观对象提供对子系统各元件功能的简化的共同层次的调用接口。代理是一种原来对象的代表，其他需要与这个对象打交道的操作都是和这个代表交涉。而适配器则不需要虚构出一个代表者，只需要为应付特定使用目的，将原来的类进行一些组合。

29.6 行为型模式一组比赛
13号选手：观察着小姐，她的口号是定义对象之间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。

14号选手：模板方法小姐，她提倡定义一个操作的算法骨架，而将一些步骤延迟到子类中，模板方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。模板方法模式由一个抽象类组成，这个抽象类定义了需要覆盖的可能有不同实现的模板方法，每个从这个抽象类派生的具体类奖为此模板实现新方法。

15号选手：命令小姐，她觉得应该将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；可以对请求排队或记录请求日志，以及支持可撤销的操作。她可以在实施操作之前将状态存储起来，以便支持取消/重做的操作。利用命令小姐可以分离请求者和实现者。

16号选手：状态小姐，她说允许一个对象在其内部状态改变时改变它的行为，让对象看起来似乎修改了它的类。状态模式提供了一个更好的方法来组织与特定状态相关的代码，决定状态转移的逻辑不在单块的if或switch中，而是分布在各个状态的子类之间，由于所有与状态相关的代码都存在于某个状态子类中，所以通过定义新的子类可以很容易地增加新的状态和转换。

17号选手：职责链小姐，她一直认为使多个对象都有机会处理请求，从而避免请求的发送者和接受者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理他为止。

MVC是包括三类对象，Model是应用对象，View是它在屏幕上的表示，Controller定义用户界面对用户输入的响应方式。如果不使用MVC，则用户界面设计往往将这些对象混在一起，而MVC则将他们分离以提高灵活性和复用性。因此有人说，她是集观察者，组合，策略三个美女优点于一身的靓女。MVC是多种模式的综合应用，应该算是一种架构模式。对于画面的事件机制，其实都是观察者模式的一种应用。

29.7行为型模式二组比赛
18号选手：解释器小姐，它声称给定一个语言，定义它的文法的一种表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子。如果一种特定类型的问题发生的频率足够高，那么就可以考虑将该问题的各个实例表述为一个简单语言中的句子。也就是说，通过构建一个解释器，该解释器解释这些句子来解决该问题。

19号选手：中介者小姐，她说她是用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变他们之间的交互。中介者负责控制和协调一组对象之间的交互。中介者充当一个中介以使组中的对象不再相互显式引用。这些对象仅知道中介者，从而减少了相互连接的数目。

20号选手：访问者小姐，她表示一个作用于某对象结构的各元素的操作。她可以在不改变各元素的类的前提下定义作用于这些元素的新操作。访问者小姐的理念就是朋友在精不在多。访问者增加具体的Element是困难的，但增加依赖于复杂对象结构的构件操作就变得容易。仅需增加一个新的访问者即可在一个对象结构上定义一个新的操作。非常有意思的交友观。