大话设计模式中的总结

背景介绍

嘉宾：

面向对象思想
抽象
封装
继承
多态

评委：

单一职责
开放封闭
依赖倒转
里氏替换
合成复用
迪米特

类型：

创建型模式
结构性模式
行为型模式

创建型比较

标题为什么需要创建型模式？

抽象工厂：

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

原型模式：

答：当一个系统应该独立于它的产品创建、构成和表示时，应该考虑用创建性模式。建立相应数目的原型并克隆它们通常比每次用合适的状态手工实例化该类更方便一些[DP]。”

依赖倒转问请谈谈你对松耦合的理解？

标题建造者模式：

答：这个问题首先要谈谈内聚性与耦合性，内聚性描述的是一个例程内部组成部分之间相互联系的紧密程度。而耦合性描述的是一个例程与其他例程之间联系的紧密程度。软件开发的目标应该是创建这样的例程:内部完整，也就是高内聚，而与其他例程之间的联系则是小巧、直接、可见、灵活的，这就是松耦合(DPE]。”

标题建造者模式是如何实现松耦合？

答：将一个复杂对象的构建与它的表示分离，这就可以很容易地改变一个产品的内部表示，并且使得构造代码和表示代码分开。这样对于客户来说，它无需关心产品的创建过程，而只要告诉我需要什么，我就能用同样的构建过程创建不同的产品给客户[DP]。”

单例模式与其它模式的不同？

对一些类来说，一个实例是很重要的。一个全局变量可以使得一个对象被访问，但它不能防止客户实例化多个对象。我的优势就是让类自身负责保存它的唯一实例。 这个类可以保证没有其他实例可以被创建，并且我还提供了一个访问该实例的方法。这样就使得对唯一的实例可以严格地控制客户怎样以及何时访问它[DP]。”

工厂模式方法对创建型模式存在的意义？

创建型模式抽象了实例化的过程。它们帮助一个系统独立于如何创建、组合和表示它的那些对象。创建型模式都会将关于该系统使用哪些具体的类的信息封装起来。允许客户用结构和功能差别很大的‘产品’ 对象配置一个系统。配置可以是静态的，即在编译时指定，也可以是动态的，就是运行时再指定。[DP]”
“我觉得她们几位都可能设计出比我更加灵活的代码，但她们的实现也相对就更加复杂。通常设计应该是从我，也就是工厂方法开始，当设计者发现需要更大的灵活性时，设计便会向其他创建型模式演化。当设计者在设计标准之间进行权衡的时候，了解多个创建型模式可以给设计者更多的选择余地。(DP]”

胜出：工厂方法

---------------------------------------------------------------------------------------

结构性模式比较

适配器模式：

面向对象的精神就是更好地应对需求的变化，而现实中往往会有下面这些情况，想使用一个已经存在的类，而它的接口不符合要求，或者希望创建一个可以复用的类，该类可以与其他不相关的类或不可预见的类协同工作。正如开放封闭所倡导地对修改关闭，对扩展开放的原则，我可以做到让这些接口不同的类通过适配后，协同工作。[DP]”

面对变化 桥接怎么做？

继承是好的东西，但往往会过度地使用，继承会导致类的结构过于复杂，关系太多，难以维护，而更糟糕的是扩展性非常差。而仔细研究如果能发现继承体系中，有两个甚至多个方向的变化，那么就解耦这些不同方向的变化，通过对象组合的方式，把两个角色之间的继承关系改为了组合的关系，从而使这两者可以应对各自独立的变化，事实上也就是合成聚合复用所提倡的原则，总之，面对变化，我主张‘找出变化并封装之’。[DPE1”
装饰怎么做？
面对变化，如果采用生成子类的方法进行扩充，为支持每一种扩展的组合，会产生大量的子类，使得子类数目呈爆炸性增长。这也是刚才桥接小姐所提到的继承所带来的灾难，而事实上，这些子类多半只是为某个对象增加一些职责，此时通过装饰的方式，可以更加灵活、以动态、透明的方式给单个对象添加职责，并在不需要时，撤销相应的职责。[DP]”

组合模式如何做到表示对象的部分与整体的层次结构？

我是希望用户忽略组合对象与单个对象的不同，用户将可以统一地使用组合结构中的所有对象。“用户使用组合类接口与组合结构中的对象进行交互，如果接收者是一个叶节点，则直接处理请求，如果接收者是组合对象，通常将请求发送给它的子部件，并在转发请求之前或之后可能执行一些辅助操作。组合模式的效果是客户可以-致地使用组合结构和单个对象。任何用到基本对象的地方都可以使用组合对象。[DP]”

外观模式对信息的隐藏促进了软件的复用[J&DP]的理解：

类之间的耦合越弱，越有利于复用，一个处在弱耦合的类被修改，不会对有关系的类造成波及。如果两个类不必彼此直接通信，那么就不要让这两个类发生直接的相互作用。如果实在需要调用，可以通过第三者来转发调用。[J&DP]"

外观模式是如何贯彻这一原则？

让一个软件中的子系统间的通信和相互依赖关系达到最小，而具体办法就是引入一个外观对象，它为子系统间提供了一个单一而简单的屏障[DP]。通常企业软件的三层或N层架构，层与层之间地分离其实就是外观模式的体现。”外观小姐说话很慢，但显然准备过，并没说错什么。迪米特满意

享元模式如何看待很多对象使得内存开销过大：

“对象使得内存占用过多，而且如果都是大量重复的对象，那就是资源的极大浪费[DP],会使得机器性能减慢，这个显然是不行的。”享元说，“面向对象技术有时会因简单化的设计而代价极大。比如文档
处理软件，当中的字符都可以是对象，而如果让文档中的每一个字 符都是一个字符对象的话，这就会产生难以接受的运行开销，显然这是不合理也是没必要的。由于文档字符就是那么些字母、数字或符号，
完全可以让所有相同的字符都共享同一个对象，比如所有用到‘a’ 的字符的地方都使用一一个共享的 ‘a’对象，这就可以节约大量的内存。”

代理模式，请对比一下你和外观模式有哪些不同?与适配器模式又区别在何处?”

代理与外观的主要区别在于，代理对象代表一个单一对象而外观对象代表一个子系统:代理的客户对象无法直接访问目标对象，由代理提供对单独的目标对象的访问控制，而外观的客户对象可以直接访问子系统中的各个对象，但通常由外观对象提供对子系统各元件功能的简化的共同层次的调用接口。[R2P]" “至于我与适配器，其实都是属于一种衔接 性质的功能。代理是一种原来对象的代表，其他需要与这个对象打交道的操作都是和这个代表交涉。而适配器则不需要虚构出一个代表者，只需要为应付特定使用目的，将原来的类进行一些组合。 [DP]”

桥接适配器外观三种模式，再次PK

适配器：

适配器说:“我主要是为了解决两个已有接口之间不匹配的问题，我不需要考虑这些接口是怎样实现的，也不考虑它们各自可能会如何演化。我的这种方式不需要对两个独立设计的类中任一个进行重新设计，就能够使它们协同工作。[DP]”

桥接：

“我觉得我和适配器小姐具有一些共同的特征，就是给另一对象提供一定程度的间接性，这样可以有利于系统的灵活性。但正所谓未雨绸缪，我们不能等到问题发生了，再去考虑解决问题，而是更应该在设计之初就想好应该如何做来避免问题的发生，我通常是在设计之初，就对抽象接口与它的实现部分进行桥接，让抽象与实现两者可以独立演化。显然，我的优势更明显。[DP]”

外观：

桥接和适配器是被用于软件生命周期的不同阶段，针对的是不同的问题，谈不上孰优孰劣。然后，对于我来说，和适配器还有些近似，都是对现存系统的封装，有人说我其实就是另外一组对象的适配器，这种说法是不准确的，因为外观定义的是一个新的接口，而适配器则是复用一个原有的接口，适配器是使两个已有的接口协同工作，而外观则是为现存系统提供一个更为方便的访问接口。如果硬要说我是适配，那么适配器是用来适配对象的，而我则是用来适配整个子系统的。也就是说，我所针对的对象的粒度更大。[DP]”

胜出：外观模式

---------------------------------------------------------------------------------------

行为型模式比较（一）

模板方法，你对代码重复的理解以及你如何实现代码重用？

“代码重复是编程中最常见、最糟糕的‘坏昧道’， 如果我们在一个以上的地方看到相同的程序结构，那么可以肯定，设法将它们合而为一，程序会变得更好[RIDEC]。但是完全相同的代码当然存在明显的重复，而微妙的重复会出现在表面不同但是本质相同的结构或处理步骤中[R2P],这使得我们一定要小心处理。继承的一个非常大的好处就是你能免费地从基类获取一些东西，当你继承一个类时，派生类马上就可以获得基类中所有的功能，你还可以在它的基础上任意增加新的功能。模板方法模式由一个抽象类组成，这个抽象类定义了需要覆盖的可能有不同实现的模板方法，每个从这个抽象类派生的具体类将为此模板实现新方法[DPE]。这样就使得，所有可重复的代码都提炼到抽象类中了，这就实现了代码的重用。”

下面请问命令模式，为什么要将请求发送者与具体实现者分离?这有什么好处?”单一职责问道。

“您的意思其实就是将调用操作的对象与知道如何实现该操作的对象解耦，而这就意味着我可以在这两者之间处理很多事，比如完全可以发送者发送完请求就完事了，具体怎么做是我的事，我可以在不同的时刻指定、排列和执行请求。再比如我可以在实施操作前将状态存储起来，以便支持取消/重做的操作。我还可以记录整个操作的日志，以便以后可以在系统出问题时查找原因或恢复重做。当然，这也就意味着我可以支持事务，要么所有的命令全部执行成功，要么恢复到什么也没执行的状态。总之，如果有类似的需求时，利用命令模式分离请求者与实现者，是最明智的选择。”

职责链模式，回答同样的问题：

“我们时常会碰到这种情况，就是有多个对象可以处理一个请求， 哪个对象处理该请求事先并不知道，要在运行时刻自动确定，此时，最好的办法就是让请求发送者与具体处理者分离，让客户在不明确指定接收者的情况下，提交一个请求，然后由所有能处理这请求的对象连成一条链， 并沿着这条链传递该请求，直到有一个对象处理它为止。

状态模式，条件分支的大量应用有何问题?如何正确看待它?

状态答道:“如果条件分支语句没有涉及重要的商务逻辑或者不会随着时间的变化而变化，也不会有任何的可扩展性，换句话说，它几乎不会变化，此时条件分支是应该使用的。但是注意我这里用到了很多前提，这些前提往往都是不成立的，事实上不会变化的需求很少，不需要扩展的软件也很少，那么如果把这样的分支语句进行分解并封装成多个子类，利用多态来提高其可维护、可扩展的需要，是非常重要的。状态模式提供了一个更好的办法来组织与特定状态相关的代码，决定状态转移的逻辑不在单块的if或switch中，而是分布在各个状态子类之间，由于所有与状态相关的代码都存在于某个状态子类中，所以通过定义新的子类可以很容易地增加新的状态和转换。[DP]”

胜出：观察者模式

---------------------------------------------------------------------------------------

行为型模式比较（二）

“请问解释器模式，说说你参赛的动机和优势?”依赖倒转问道。

解释器小姐很镇定地答道:“在编程世界里，实现目标都是通过编写语言并执行来实现的，从最低级的机器语言到人能很容易读懂机器也可以执行的高级语言，但是高级语言编写起一些问题 可能还是比较复杂。如果一种特定类型的问题发生的频率足够高，那么就可以考虑将该问题的各个实例表述为一个简单语言中的句子。也就是说，通过构建一个解释器，该解释器解释这些句子来解决该问题[DP]。比
如正则表达式就是描述字符串模式的一种标准语言， 与其为每一个字 符串模式都构造一个特定的算法，不如使用一种通用的搜索算法来解释执行一个正则表达式，该正则表达式定义了待匹配字符器的集合[DP]。”

“中介者模式，人家都说你是交际花，请问你广交朋友的目的是什么?”迪米特问道。

“交际花不敢当，但我的确喜欢交朋友。面向对象设计鼓励将行为分布到各个对象中，这种分布可能会导致对象间有许多连接。也就是说，有可能每一个对象都需要知道其他许多对象。对象间的大量相互连接使得一个对象似乎不太可能在没有其他对象的支持下工作，这对于应对变化是不利的，任何较大的改动都很困难[DP]。所以说朋友多既是好事情，其实也是坏事情。我提倡将集体行为封装一个单独的中介者对象来避免这个问题，中介者负责控制和协调一组对象间的交互。中介者充当一个中介以使组中的对象不再相互显式引用。这些对象仅知道中介者，从而减少了相互连接的数目[DP]。我作为中介者，广交朋友，就起到了在朋友间牵线搭桥的作用。可以为各位朋友们服务。这其实不也正是迪米特先生您一直倡导的最少知识原则，也就是如何减少耦合的问题，类之间的耦合越弱，越有利于复用[J&DP]。"

合成聚合复用问道: “访问者模式，听说你对朋友要求很苛刻，要请到你帮忙是很难的事情，你喜欢交朋友吗?”

听到这个问题，访问者笑开了颜:“哪有这种事情，朋友要我帮忙，我都会尽力而为的。的确，我不太喜欢交很多朋友，一般找到好朋友了，就不喜欢再交往新的朋友了。我的理念是朋友在精不在多。但是我和朋友间的交往通常会是多方面的，一同聊天、逛街、旅游、唱歌、游泳，哪怕是我们不会的活动，我们也可以尝试起去学习、去扩展我们的生活情趣。也就是说，访问者增加具体的Element是困难的，但增加依赖于复杂对象结构的构件的操作就变得容易。仅需增加一个新的访问者即可在一个对象结构.上定义一个新的操作。”

“请问策略模式，说说你对‘优先使用对象组合，而非类继承’的理解?”合成聚合复用问道。

策略小姐答得很流利，“继承提供了一种支持多种算法或行为的方法，我们可以直接生成一个类A的子类B、C、D,从而给它以不同的行为。但这样会将行为硬行编制到父类A当中，而将算法的实现与类A的实现混合起来，从而使得类A难以理解、难以维护和难以扩展，而且还不能动态地改变算法。仔细分析会发现，它们之间的唯一差别是它们所使用的算法或行为，将算法封装在独立的策略Strategy类中使得你可以独立于其类A改变它，使它易于切换、易于理解、 易于扩展[DP]。这里显然使用对象组合要优于类继承。”

“请问一下备忘录模式，在保存对象的内部状态时，为何需要考虑不破坏封装细节的前提?”单一职责问道。

“通常原对象A都有很多状态属性，保存对象的内部状态，其实也就是将这些状态属性的值可以记录到A对象外部的另一个对象B,但是，如果记录的过程是对外透明的，那就意味着保存过程耦合了对象状态细节。使用备忘录就不会出现这个问题，它可以避免暴露-些 只应由对象A管理却又必须存储在对象A之外的信息。备忘录模式把可能很复杂的对象A的内部信息对其他对象屏蔽起来，从而保持了封装边界[DP]。

“迭代器模式，说说迭代器模式对遍历对象的意义?”里氏代换问道。

“一个集合对象，它当中具体是些什么对象元素我并不知道，但不管如何，应该提供一种方法来让别人可以访问它的元素，而且可能要以不同的方式遍历这个集合。迭代器模式的关键思想是将对列表的访问和遍历从列表对象中分离出来并放入一个迭代器对象中，迭代器类定义了一个访问该列表元素的接口。迭代器对象负责跟踪当前的元素，并且知道哪些元素已经遍历过了[DP]。”

胜出：策略模式

插图（一）设计模式PK

插图（二）设计模式的UML图

uml类图连接：https://download.csdn.net/download/lsyrhz/12526138。

以上为本人学习《大话设计模式》一书的简单总结，随着以后对设计模式理解的加深，会记录更优质的学习笔记。也欢迎各位大佬提出指点。