UML和模式应用读书笔记七(GoF)

Adapter

问题:如何解决不相容的接口问题,或者如何为具有不同接口的类似构件提供稳定的接口
建议:通过中介适配器对象,将构件的原有接口转换为其他接口

类型名称中包含了模式名称Adapter.这是相对常见的风格,这使得其他人在阅读代码或图形时能够很容易理解其中使用了哪些模式.

Factory

如果是某个领域对象来创建这些适配器,那么领域对象的职责会超出了单纯的应用逻辑(例如销售总额的计算),并且会涉及与外部软件构件连接相关的其他内容.

工厂对象如下一些优势:

• 分离复杂创建的职责,并将其分配给内聚的帮助者对象
• 隐藏潜在的复杂创建逻辑
• 允许引入提高性能的内存管理策略,例如对象缓存或再生

注意:在ServicesFactory中,决定使用哪个类来创建的逻辑是,从外部源读取类的名称(例如,如果使用Java则以系统特性文件作为外部源),然后动态加载这个类.此例中,局部地使用了数据驱动设计.这种设计对于实现适配器类的变化方面做到了防止变异原则.无需更改工厂类中的源代码,通过修改属性值并且确保新类存在于Java的类路径中,我们就可以为新的适配器类创建实例.

Singleton

ServicesFactory的设计又引发了另一个新问题:由谁来创建工厂自身,如何访问工厂?
首先,注意在该过程中只需要一个工厂实例…有一种解决方案是,将ServicesFactory作为参数传递给任何需要其可见性的地方…另一种替代方案是单实例模式

单实例的实现还存在另一个问题:为什么不将所有服务方法都定义成类自己的静态方法,而是使用具有实例方法的实例对象?

• 实例方法允许定义单实例类的子类,以对其进行精化;静态方法不是多态的而且在大多数语言中不允许在子类中对其重写
• 大多数面向对象的远程通信机制只支持实例方法的远程使用,而不支持静态方法
• 类并非在所有场景中都是单实例的.

面对上面的理由二,工厂会成为远程方法么?
上面的理由三也说不过去,如果工厂的目的是为了得到实例,并且我们没有两个实例从同一个工厂产生的约束,二者没有差别,毕竟可以鞋厂以下形式:

class Factory{
	public static Factory getInstance(){
		//....some code
	}
	public Adapter getAdapter(){
		//....some code
	}
	public static Adapter getAdapterStatic(){
		return getInstance().getAdapter();
	} 
}

可以看出上面第三个方法完全可以通过前两个方法来实现,减少了调用者的次数并且实现结果一样.

Strategy

策略对象将依附于语境对象—策略对象对其应用算法.在本例中,语境对象是Sale.当getTotal消息被发送给Sale时,它会把部分工作委派给它的策略对象.其中并不要求发给语境对象和策略对象的消息具有相同的名称,但是这种做法十分常见.无论如何,语境对象会将其自身的引用传递给策略对象,这种做法十分普遍…

策略是基于多态的,并且对于变化的算法提供了防止变异.策略通常由工厂创建.

Composite

定义组合和原子对象的类,使他们实现相同的接口

Facade

Observer/Publish-Subscribe

Template Method

该模式的思想是,在超类中定义一种方法(模板方法),超类定义了算法的框架,其中既有固定部分也有变化部分.Template方法调用其他一些方法,这些方法可能会被子类覆写.

这里需要使用protected,在类图中,它是表示为#

Do It Myself

State

问题:对象的行为依赖于它的状态,而它的方法中包含能够反映依赖状态的条件动作的case逻辑.是否存在替代条件逻辑的方法
方案:给每个状态创建状态类,并实现一个公共接口.将语境对象中依赖于状态的操作委派给其当前的状态对象.

Command

为每一个任务创建一个类,并实现共同的接口

一般为XXXCommand,然后有一个execute方法