大话设计模式 学习笔记 03
大话设计模式 03
插话
合成/聚合复用原则。在设计关系中，优先使用对象合成/聚合，而不是类继承。
导航
组合模式
将对象组合成属性结构以表示‘部分-整体’的层次结构。组合模式使得用户对单个对象和组合对象的使用具有一致性。
透明方式和安全方式
透明方式：也就是说在Component中生命所有用来管理子对象的方法。其中包括Add、Remove等。这样实现Component接口的所有子类都具备了Add和Remove。这样做的好处就是叶节点和枝节点对于外界没有区别，它们具备完全一致的行为接口。问题同样明显，因为Leaf类本身不具备Add()、Remove()方法的功能，所以实现它是没有意义的。
安全方式：在Component接口中不生命Add和Remove方法，那么子类的Leaf也就不需要去实现它，但而是在Composite声明所有用来管理子类对象的方法。由于不够透明，所以树叶和树枝类将不具有相同的接口，客户端的调用需要做相应的判断，带来了不便。
使用时机
需求中是体现部分与整体层次的结构式，希望用户可以忽略组合对象与单个对象的不同，统一地使用组合结构中的素有对象时，就应该考虑用组合模式。
好处
用户不再关系到底处理了一个叶节点还是处理一个组合组建，也就不用为定义组合而写判断语句。
组合模式让用户可以一致的使用组合结构和单个对象。
迭代器模式
提供一种方法顺序访问一个聚合对象中各个元素，而又不暴露该对象的内部表示。
使用场景
需要访问一个聚焦对象，而且不管这些对象是什么都需要便利的时候，你就应该考虑用迭代器模式。
当对聚集有多重方式遍历时，可以考虑用迭代器模式。
为便利不同的聚集结构提供如开始、下一个、是否结束、当前哪一项等统一的接口。
迭代器模式就是分离了结合对象的便利行为，抽象出一个迭代器类来负责，这样既可以不暴露集合的内部结构，又可以让外部代码透明的访问集合内部的数据。
单例模式
所有类都有构造方法，不编码则系统默认生成空的构造方法，若有显示定义的构造方法，默认的构造方法就会失效。
保证一个类仅有一个实例，并提供一个访问它的全局访问点。
通常我们可以让一个全局变量使得一个对象被访问，但它不能防止你实例化多个对象，一个最好的办法就是，让类自身负责保护它的唯一实例。这个类可以保证没有其他实例可以被创建，并且它可以提供一个访问该实例的方法。
好处
单例模式因为Singleton类封装它的唯一实例，这样它可以严格的控制客户怎样访问它以及何时访问它，简单的说就是对唯一实例的受控访问。
Bad Case --- 多线程的单例
多线程同时访问GetInstance时，需要加锁处理，lock能确保当前一个线程位于代码的临界区是，另一个线程不进入临界区。
优化点：
如果Lock(instance)，媒体调用GetInstance都需要加锁，影响性能，可以使用进程辅助对象来改良（P216）
先判断是否存在 -> 不存在再加锁初始化 双重锁定 (Double-Check Locking, 需要注意在进程辅助的加锁判断内部同样需要判断静态对象是否已经初始化)
桥接模式
过度使用继承缺点
对象的继承关系是在编译时定义好的，所以无法在运行时改变从父类继承的实现。子类的实现与它的父类有非常紧密的依赖关系，以至于父类实现中的任何变化必然会导致子类发生变化。当你需要复用子类时，如果继承下来的实现不适合解决新的问题，则父类必须重写或被其他更适合的类替换。这种一类关系限制了灵活性最终限制了复用性
解决
合成/聚合复用原则（CARP)
尽量使用合成/聚合，尽量不要使用类继承。
聚合表示一种弱拥有关系，体现的是A对象可以包含B，但B对象不是A对象的一部分；
合成表示一种强拥有关系，体现严格的部分和整体的关系，部分和整体的生命周期一样。
好处
优先使用对象的合成/聚合将有助于保持每个类被封装，并集中在单个任务上。这样类和类继承层次会保持较小规模，并且不太可能增长为不可控制的庞然大物。
相比于继承：继承是一种强耦合结构，继承的使用时机，一定是is-a的关系
桥接模式：将抽象部分与实现部分分离，是他们都可以独立地变化
抽象与实现分离：并不是说让抽象类与其派生类分离，这明没有意义，实现值得是抽象类和它的派生类用来实现自己的对象。
对于一个场景的实现方式有多种，使用桥接模式的核心意图是把这些实现独立出来，让它们各自变化，是的每种实现的变化不会影响其他的实现，从而达到应对变化的目的。
二次解释“将抽象部分与实现部分分离”
实现系统可能有多角度分类，每一种分类都有可能变化，那么就把这种多角度分离出来，让它们独立变化，减少它们之间的耦合
命令模式
将一个请求封装为一个对象，从而是你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可撤销的操作。
优点
-
比较容易地设计一个命令队列
-
在需要的情况下，可以较容易地将命令记入日志
-
允许接受请求的一方决定是否要否决请求
-
容易地实现对请求的撤销和重做
-
新加入的具体志玲类不影响其他的类，扩展起来很方便
-
命令模式把请求一个操作的对象与知道怎么执行一个操作的对象分割开
什么时候实现？
敏捷开发原则告诉我们，不要为代码添加基于猜测的、实际不需要的功能，如果不清楚一个系统是否需要命令模式，一般就不要着急去实现它，事实上，在需要的时候通过重构实现这个模式并不困难，只有在真正需要如撤销/恢复操作等功能时，把原来的代码重构为命令模式才有意义。
职责链模式
使多个对象都有机会处理请求，从而避免请求的发送者与接受者之间的耦合关系。将这个对象连城一条链。并沿着这条链传递该请求，知道又一个对象处理它为止。
关键
当客户提交一个请求时，请求是沿链传递直至有一个ConcreteHandler对象负责处理它。
好处
接受者和发送者都没有对方的明确信息，且链中的对象自己也并不知道链的结构。结果是职责链可简化对象的相互链接，它们仅需要保持一个指向其后继者的引用，而不需保持它所有的候选接受者的引用。
可以随时增加或修改处理一个请求的结构。增强了给对象指派职责的灵活性。
需要注意：一个请求极有可能盗了链的末端都得不到处理，或者因为没有正确配置而得不到处理。
中介者模式
用一个中介对象来封装一些列的对象交互。中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。
中介者模式很容易在系统中应用，也很容易在系统中误用，当系统出现了‘多对多交互复杂的对象群时，不要急于使用中介者模式，而要先反思你的系统在设计上是不是合理。
优点
中介的出现减少了哥哥Colleague的耦合，使得可以独立地改变和复用哥哥Colleague类和Mediator
由于把对象如何写作进行了抽象，将中介作为一个独立地概念并将其封装在一个对象中，这样关注的对象就从对象各自本身的行为转移到它们之间的交互上来，也就是站在一个更宏观的角度看待系统。
缺点
由于ConcreteMediator控制了集中化，于是就把交互复杂性变成了中介者的复杂性，这就使得中介者会变得比任何一个ConcreteColleague都复杂。
中介者模式一般应用于一组对象以定义良好但是复杂的方式进行通信的场合，应用于想定制一个分布在多个类中的行为，而又不想声称太多子类的场合。
享元模式
运用共享技术有效地支持大量细粒度的对象。
享元模式可以避免大量非常相似类的开销。在程序设计中，有时需要声称大量细粒度的类实例来表示数据。如果能发现这些实例除了几个参数外基本上都是相同的，有时就能够受大幅度地减少需要实例化的类的数量。如果能把那些参数移到类实例的外边，在方法调用时将他们传递进来，就可以通过共享大幅度地减少单个实例的树木。
使用背景
如果一个应用程序使用了大量的对象，而大量的这些对象造成了很大的存储开销时就应该考虑使用；
对象的大读书状态可以外部状态，如果删除对象的外部状态，那么可以用相对较少的共享对象取代很多组对象，此时可以考虑使用享元模式。
解释器模式
给定一个语言，定义它的文法的一种表示，并定义一个解释器，这个解释器使用该表示来皆是语言中的句子。
解决的问题
如果一种特定类型的问题发生的频率足够高，那么可能就值得将该问题的各个实例表述为一个简单语言中的句子。这样就可以构建一个解释器，该解释器通过解释这些句子来解决该问题。
使用背景
当有一个语言需要执行解释执行，并且你可将该语言中的句子表示为一个抽象语法树时，可使用解释器模式。
好处
容易改变和扩展文法，因为该模式使用类来表示文法规则，你可使用继承来改变或扩展该文法。也比较容易实现文法，因为定义抽象语法树中各个节点的类的实现答题蕾丝，这些类都易于直接编写。
缺点
解释器模式为文法中的每条规则都至少定义了一个类，因此包含许多规则的文法可能难以管理和维护。建议当文法非常复杂时，使用其他的技术如愈发分析程序或编译器生成器来处理。
访问者模式
表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。
访问者模式适用于数据结构相对稳定的系统。
它把数据结构和作用于结构上的操作之间的耦合解开，是的操作集合可以相对自由的演化。
目的
把处理从数据结构分离出来。
如果系统有比较稳定的数据结构，又有易于变化的算法的话，，就适用于访问者模式，访问者模式使得算法的增加变得容易。
优点
增加新的操作容易，因为新的操作等于增加一个新的访问者。访问者模式将有关的行为集中到一个访问者对象中。
缺点
使得新增数据结构变得困难。
浙公网安备 33010602011771号