标签：图解 角色 读书笔记 Composite 模式 实例 使用 设计模式
图解设计模式 读书笔记
- 类名是束缚吗
话说回来，在源程序中使用类名到底会有什么问题呢?在代码中出现要使用的类的名字不是理所当然的吗?
这里，让我们再回忆一下面向对象编程的目标之一，即“作为组件复用”。
在代码中出现要使用的类的名字并非总是坏事。不过，一旦在代码中出现要使用的类的名字，就无法与该类分离开来,也就无法实现复用。
当然，可以通过替换源代码或是改变类名来解决这个问题。但是，此处说的“作为组件复用”中不包含替换源代码。以Java来说，重要的是当手边只有class文件( .class )时，该类能否被复用。即使没有Java文件( .java)也能复用该类才是关键。
当多个类必须紧密结合时，代码中出现这些类的名字是没有问题的。但是如果那些需要被独立出来作为组件复用的类的名字出现在代码中，那就有问题了。
- clone方法是在哪里定义的
clone方法定义在java.lang.0bject中。因为object类是所有Java类的父类，因此所有的Java类都继承了clone方法。
- 需要实现Cloneable的哪些方法
提到cloneable接口，很容易让人误以为cloneable接口中声明了clone方法。其实这是错误的。在cloneable接口中并没有声明任何方法。它只是被用来标记“可以使用c1one方法进行复制”的。这样的接口被称为标记接口( marker interface ).
- clone方法进行的是浅复制
clone方法所进行的复制只是将被复制实例的字段值直接复制到新的实例中。换言之，它并没有考虑字段中所保存的实例的内容。例如，当字段中保存的是数组时，如果使用clone方法进行复制，则只会复制该数组的引用,并不会—一复制数组中的元素。
像上面这样的字段对字段的复制( field-to-field-copy)被称为浅复制( shallow copy )。clone方法所进行的复制就是浅复制。
当使用clone方法进行浅复制无法满足需求时，类的设计者可以实现重写clone方法，实现自己需要的复制功能(重写clone方法时，别忘了使用super.clone ()来调用父类的clone方法)。
需要注意的是，clone方法只会进行复制，并不会调用被复制实例的构造函数。此外，对于在生成实例时需要进行特殊的初始化处理的类，需要自己去实现clone方法，在其内部进行这些初始化处理。
详细信息请参见Java的API参考资料中java.lang.0bject类的clone方法和Cloneable接口这两个相关条目。
第1章 Iterator模式——一个一个遍历
相关的设计模式
- Visitor模式(第13章)
Iterator模式是从集合中一个一个取出元素进行遍历，但是并没有在Iterator接口中声明对取出的元素进行何种处理。
Visitor模式则是在遍历元素集合的过程中，对元素进行相同的处理。
在遍历集合的过程中对元素进行固定的处理是常有的需求。Visitor模式正是为了应对这种需求而出现的。在访问元素集合的过程中对元素进行相同的处理，这种模式就是Visitor模式。
- Composite模式(第11章)
Composite模式是具有递归结构的模式，在其中使用Iterator模式比较困难。Factory Method模式(第4章)
在iterator方法中生成Iterator的实例时可能会使用Factory Method模式。
第2章 Adapter模式——加个“适配器”以便于复用
相关的设计模式
- Bridge模式(第9章)
Adapter模式用于连接接口(API)不同的类，而Bridge模式则用于连接类的功能层次结构与实现层次结构。
- Decorator模式(第12章)
Adapter模式用于填补不同接口(API)之间的缝隙，而Decorator模式则是在不改变接口(API)的前提下增加功能。
第3章 Template Method模式——将具体处理交给子类
相关的设计模式
- Factory Method模式(第4章)
Factory Method模式是将Template Method模式用于生成实例的一个典型例子。
- Strategy模式(第10章)
在Template Method模式中，可以使用继承改变程序的行为。这是因为Template Method模式在父类中定义程序行为的框架,在子类中决定具体的处理。
与此相对的是Strategy模式，它可以使用委托改变程序的行为。与Template Method模式中改变部分程序行为不同的是，Strategy模式用于替换整个算法。
第4章 Factory Method模式——将实例的生成交给子类
相关的设计模式
- Template Method模式(第3章)
Factory Method模式是Template Method 的典型应用。在示例程序中，create方法就是模板方法。
- Singleton模式(第5章）
在多数情况下我们都可以将Singleton模式用于扮演Creator角色(或是ConcreteCreator角色)的类。这是因为在程序中没有必要存在多个Creator角色(或是ConcreteCreator角色)的实例。不过在示例程序中,我们并没有使用Singleton模式。
- Composite模式(第11章)
有时可以将Composite模式用于Product 角色(或是ConcreteProduct角色)lterator模式(第1章)
有时，在Iterator模式中使用iterator方法生成Iterator的实例时会使用Factory Method模式。
第5章 Singleton模式——只有一个实例
相关的设计模式
在以下模式中,多数情况下只会生成一个实例。
- AbstractFactory模式(第8章)
- Builder模式(第7章）
- Facade模式(第15章)
- Prototype模式（第6章)
第6章 Prototype模式——通过复制生成实例
相关的设计模式
Flyweight模式(第20章)
使用Prototype模式可以生成一个与当前实例的状态完全相同的实例。而使用Flyweight模式可以在不同的地方使用同一个实例。
Memento模式(第18章)
使用Prototype模式可以生成一个与当前实例的状态完全相同的实例。而使用 Memento模式可以保存当前实例的状态,以实现快照和撤销功能。Composite模式(第11章)以及Decorator模式(第12章)
经常使用Composite模式和 Decorator模式时，需要能够动态地创建复杂结构的实例。这时可以使用Prototype模式，以帮助我们方便地生成实例。
Command模式(第22章)
想要复制Command模式中出现的命令时，可以使用Prototype模式。
第7章 Builder模式——组装复杂的实例
7.4相关的设计模式
Template Method模式(第3章）
在 Builder模式中，Director 角色控制Builder角色。在Template Method模式中，父类控制子类。RComposite模式(第11章)
有些情况下 Builder模式生成的实例构成了Composite模式。Abstract Factory模式(第8章)
Builder模式和Abstract Factory模式都用于生成复杂的实例。Facade模式(第15章)
在Builder模式中，Director角色通过组合Builder角色中的复杂方法向外部提供可以简单生成实例的接口(API )(相当于示例程序中的construct方法)。
Facade模式中的Facade角色则是通过组合内部模块向外部提供可以简单调用的接口(API )。
第8章 Abstract Factory模式——将关联零件组装成产品
相关的设计模式
- Builder模式(第7章)
Abstract Factory模式通过调用抽象产品的接口(API)来组装抽象产品，生成具有复杂结构的实例。
Builder模式则是分阶段地制作复杂实例。
- Factory Method模式(第4章)
有时Abstract Factory模式中零件和产品的生成会使用到Factory Method模式。Composite模式(第11章)
有时Abstract Factory模式在制作产品时会使用Composite模式。
- Singleton模式(第5章)
有时Abstract Factory模式中的具体工厂会使用Singleton模式。
第9章 Bridge模式——将类的功能层次结构与实现层次结构分离
- Template Method模式(第3章)
在Template Method模式中使用了“类的实现层次结构”。父类调用抽象方法，而子类实现抽象方法。
- Abstract Factory模式(第8章)
为了能够根据需求设计出良好的ConcreteImplementor角色，有时我们会使用AbstractFactory模式。
- Adapter模式(第2章)
使用 Bridge模式可以达到类的功能层次结构与类的实现层次结构分离的目的，并在此基础上使这些层次结构结合起来。
而使用Adapter模式则可以结合那些功能上相似但是接口(API)不同的类。
第10章 Strategy模式——整体地替换算法
相关的设计模式
- Flyweight模式(第20章)
有时会使用Flyweight模式让多个地方可以共用ConcreteStrategy 角色。Abstract Factory模式(第8章)
使用Strategy模式可以整体地替换算法。
使用Abstract Factory模式则可以整体地替换具体工厂、零件和产品。
- State模式(第19章)
使用Strategy模式和State模式都可以替换被委托对象，而且它们的类之间的关系也很相似。但是两种模式的目的不同。
在Strategy模式中，ConcreteStrategy角色是表示算法的类。在Strategy模式中，可以替换被委托对象的类。当然如果没有必要，也可以不替换。
而在State模式中，ConcreteState角色是表示“状态”的类。在State模式中，每次状态变化时，被委托对象的类都必定会被替换。
第11章 Composite模式——容器与内容的一致性
相关的设计模式
- Command模式(第22章)
使用Command模式编写宏命令时使用了Composite模式。
- Visitor模式(第13章)
可以使用Visitor模式访问Composite模式中的递归结构。
- Decorator模式(第12章)
Composite模式通过Component角色使容器(Composite角色)和内容( Leaf角色)具有一致性。
Decorator模式使装饰框和内容具有一致性。
第12章 Decorator模式——装饰边框与被装饰物的一致性
相关的设计模式
- Adapter模式(第2章）
Decorator模式可以在不改变被装饰物的接口(API)的前提下，为被装饰物添加边框（透明性)。
Adapter模式用于适配两个不同的接口(API )。
- Stragety模式(第10章)
Decorator模式可以像改变被装饰物的边框或是为被装饰物添加多重边框那样，来增加类的功能。
Stragety模式通过整体地替换算法来改变类的功能。
第13章 Visitor模式——访问数据结构并处理数据
相关的设计模式
- lterator模式(第1章）
Iterator模式和Visitor模式都是在某种数据结构上进行处理。lterator模式用于逐个遍历保存在数据结构中的元素。
Visitor模式用于对保存在数据结构中的元素进行某种特定的处理。
- Composite模式(第11章)
有时访问者所访问的数据结构会使用Composite模式。
- lnterpreter模式(第23章)
在 Interpreter模式中，有时会使用Visitor模式。例如，在生成了语法树后，可能会使用Visitor模式访问语法树的各个节点进行处理。
第14章 Chain of Responsibility模式——推卸责任
相关的设计模式
- Composite模式(第11章）
Handler角色经常会使用Composite模式。
- Command模式(第23章)
有时会使用Command模式向Handler角色发送请求。
第15章 Facade模式——简单窗口
相关的设计模式
- Abstract Factory模式(第8章)
可以将Abstract Factory模式看作生成复杂实例时的Facade模式。因为它提供了“要想生成这个实例只需要调用这个方法就OK了”的简单接口。
- Singleton模式(第5章)
有时会使用Singleton模式创建Facade角色。Mediator模式(第16章)
在 Facade模式中，Facade角色单方面地使用其他角色来提供高层接口(API ).
而在 Mediator模式中，Mediator角色作为Colleague角色间的仲裁者负责调停。可以说，Facade模式是单向的,而 Mediator角色是双向的。
第16章 Mediator模式——只有一个仲裁者
相关的设计模式
- Facade模式(第15章)
在 Mediator模式中，Mediator角色与Colleague角色进行交互。
而在Facade模式中，Facade角色单方面地使用其他角色来对外提供高层接口(API)。因此，可以说Mediator模式是双向的,而Facade模式是单向的。
- Observer模式(第17章)
有时会使用Observer模式来实现Mediator角色与Colleague角色之间的通信。
第17章 Observer模式——发送状态变化通知
相关的设计模式
- Mediator模式(第16章)
在Mediator模式中，有时会使用Observer模式来实现 Mediator角色与Colleague角色之间的通信。就“发送状态变化通知”这一点而言，Mediator模式与Observer模式是类似的。
不过，两种模式中，通知的目的和视角不同。
在Mediator模式中，虽然也会发送通知，不过那不过是为了对Colleague角色进行仲裁而已。
而在Observer模式中，将Subject角色的状态变化通知给Observer 角色的目的则主要是为了使Subject角色和 Observer 角色同步。
第18章 Memento模式——保存对象状态
相关的设计模式
- Command模式(第22章)
在使用Command模式处理命令时，可以使用Memento模式实现撤销功能。
- Protype模式(第6章)
在 Memento模式中，为了能够实现快照和撤销功能，保存了对象当前的状态。保存的信息只是在恢复状态时所需要的那部分信息。
而在 Protype模式中，会生成一个与当前实例完全相同的另外一个实例。这两个实例的内容完全一样。
- State模式(第19章)
在 Memento模式中，是用“实例”表示状态。而在 State模式中，则是用“类”表示状态。
第19章 State模式——用类表示状态
相关的设计模式
- Singleton模式(第5章)
Singleton模式常常会出现在ConcreteState角色中。在示例程序中，我们就使用了Singleton模式。这是因为在表示状态的类中并没有定义任何实例字段(即表示实例的状态的字段)。
- Flyweight模式(第20章)
在表示状态的类中并没有定义任何实例字段。因此，有时我们可以使用Flyweight模式在多个Context角色之间共享ConcreteState角色。
第20章 Flyweight模式——共享对象，避免浪费
相关的设计模式
- Proxy模式(第21章)
如果生成实例的处理需要花费较长时间，那么使用Flyweight模式可以提高程序的处理速度。
而Proxy模式则是通过设置代理提高程序的处理速度。
- Composite模式(第11章)
有时可以使用Flyweight模式共享Composite模式中的Leaf角色。
- Singleton模式(第5章）
在FlyweightFactory角色中有时会使用Singleton模式。
此外，如果使用了Singleton模式，由于只会生成一个Singleton角色，因此所有使用该实例的地方都共享同一个实例。在 Singleton角色的实例中只持有intrinsic信息。
第21章 Proxy模式——只在必要时生成实例
相关的设计模式
- Adapter模式(第2章)
Adapter模式适配了两种具有不同接口(API )的对象，以使它们可以一同工作。而在 Proxy模式中,Proxy 角色与 RealSubject角色的接口(API)是相同的(透明性)。
- Decorator模式(第12章)
Decorator模式与Proxy模式在实现上很相似，不过它们的使用目的不同。
Decorator模式的目的在于增加新的功能。而在Proxy模式中，与增加新功能相比，它更注重通过设置代理人的方式来减轻本人的工作负担。
第22章 Command模式——命令也是类
相关的设计模式
- Composite模式(第11章)
有时会使用Composite模式实现宏命令( macrocommand )。
- Memento模式(第18章)
有时会使用Memento模式来保存Command角色的历史记录。
- Protype模式(第6章)
有时会使用Protype模式复制发生的事件(生成的命令)。
第23章 Interpreter模式——语法规则也是类
相关的设计模式
- Composite模式(第11章)
NonterminalExpression 角色多是递归结构，因此常会使用Composite模式来实现NonterminalExpression角色。
- Flyweight模式(第20章)
有时会使用Flyweight模式来共享TerminalExpression角色。Visitor模式(第13章)
在推导出语法树后,有时会使用Visitor模式来访问语法树的各个节点。
标签：图解,角色,读书笔记,Composite,模式,实例,使用,设计模式 来源： https://www.cnblogs.com/LiPengFeiii/p/15359326.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。