Java设计模式（刘伟）的思考题个人回答2

在组合模式结构图中，如果聚合关联关系不是从Composite到Component的，而是从Composite 到Leaf的，如图11-4所示，会产生怎样的结果？

我的回答：【聚合关系】：是整体与部分的关系，且部分可以离开整体而单独存在。如车和轮胎是整体和部分的关系，轮胎离开车仍然可以存在。这个层级关系，似乎有点问题。

如何编码实现图11-9中的“公司”类？

我的回答：继承抽象类，定义集合，用于储存单位类型的成员。然后实现添加删除获得定义的方法。

能否在装饰模式中找出两个独立变化的维度？试比较装饰模式和桥接模式的相同之处和 不同之处？

我的回答：可以，一个维度是“被装饰类”本来的方法，另一个维度则是装饰类加的一些操作。桥接模式像是把多个维度组在一起，装饰模式更像洋葱，一个一个维度，裹上去。

为什么半透明装饰模式不能实现对同一个对象的多次装饰？

我的回答：如何传入一个具体装饰类型的对象？由于代换原则，将会损失具体装饰类型的独有的方法。

如何在客户端创建一条职责链？

我的回答：创造每一个职责模块，然后再客户端把关系链拼装在一起。

如果将审批流程由“主任–>副董事长–>董事长–>董事会”调整为“主任–>董事长–>董事 会”，系统将做出哪些改动？预测修改之后客户端代码的输出结果

我的回答：将主任的下家设置为董事长即可。

一个请求发送者能否对应多个请求接收者？如何实现？

我的回答：可以啊，发多条不同的命令就行了。

如果连续调用“form.undo()”两次，预测客户端代码的输出结果。

我的回答：5

绘制加法/减法解释器的类图并编写核心实现代码。

我的回答：

class AddExpression extends AbstractExpression {
	public void interpret(Context ctx) {
		return “加”
	}
}
class MinisExpression extends AbstractExpression {
	public void interpret(Context ctx) {
		return “减”
	}
}

理解迭代器模式中具体聚合类与具体迭代器类之间存在的依赖关系和关联关系。

我的回答：具体聚合类举例可以是有一个类，有一个arrayList类型局部变量的，这个聚合类有个方法，可以生成具体的迭代器。用这个迭代器，可以操纵这个具体聚合类里的arrayList，是通过把这个聚合类传入到迭代器类来实现的，大概是这么个逻辑。

为什么使用iterator()方法创建的迭代器无法实现逆向遍历？

我的回答：因为该抽象接口根本没有这个方法。

如何理解同事类中的自身方法与依赖方法？

我的回答：自身方法就是，自己要完成的方法，比如自己变颜色什么的；依赖方法就是，其他相关同事类要跟着调用的方法。

如果不使用中介者模式，按照图20-3所示设计方案，增加新组件时原有系统该如何修改？

我的回答：全部具体类都要改一遍。

能否通过原型模式来创建备忘录对象？系统该如何设计？

我的回答：可以啊。将备忘录类当做原发器类的内部类即可。负责人类的方法也并入。

如何使用内部类来实现备忘录模式？

我的回答：

原生类（）{
	private 状态 state;
	private 负责人类 caretaker;
	class 备忘录类（）{
		//存储状态
	}
	class 负责人类（）{
		//存储备忘录类
	}
	private method（）{
		//各种从负责人类里拿到备忘录类，去更新状态
		//或者生成备忘录类，去储存状态
		//如果状态是一个基础值的话，没有备忘录类感觉也可以
	}
}

观察者模式是否符合“开闭原则”？【从增加具体观察者和增加具体目标类两方面考虑。】

我的回答：如果具体观察者要用到具体目标类里的状态的话：1、增加具体观察者符合开闭原则 2、增加具体目标类可能不符合。如果具体观察者没有用到具体目标类里的状态的话，符合开闭原则。

理解两种状态转换方式的异同？

我的回答：统一由环境类来负责状态之间的转换：比较统一，也不用再具体状态里写代码了，新增具体状态肯定要改修改状态的代码。由具体状态类来负责状态之间的转换：每个具体类都要实现，状态改变的代码，代码写的比上面这种多，好处是，新增一个状态可能只要改几个具体状态类就行。

一个环境类Context能否对应多个不同的策略等级结构？如何设计？

我的回答：可以啊，在环境类储存的将不是单个策略类，而是储存一个策略集合，策略的等级设计将由这个集合设计。

双重分派机制如何用代码实现？

我的回答：

具体元素类A（）{
	方法（抽象访问类）{
		访问类.处理方法（本类）
	}
}
具体访问类（）{
	处理方法（元素类A）{
		//对元素a的处理
	}
}
对象结构类（）{
	具体元素类集合
	处理方法（抽象访问类）{
		for(){
			具体元素.方法（访问类）
		}
	}
}

访问者模式是否符合“开闭原则”？【从增加新的访问者和增加新的元素两方面考虑。】

我的回答：新增访问者类型，符合开闭原则，只要新增的访问者类实现对现有的具体类的处理即可。增加新的元素，不符合开闭原则，需要对现有的所有的访问者类型都增加对新增元素的处理。

结束语

看完这二十几个设计模式，其实解决的招式也无非就是继承，接口什么的，主要是从问题的模式方面去区分。