4.5逻辑架构的设计
根据模型—视图分离原则规定，模型（领域）对象不应该直接与视图（UI）对象连接，对于视图对象也是如此。
观察者（Observer）模式是对该原则的合理扩展，即领域对象只能通过PropertyListener（Java中的常用接口）的接口向视图的UI对象发送消息。基于该模式，领域对象不知道UI对象的存在，即不知道它的具体窗口类。领域对象只需发送消息给实现了PropertyListener接口的对象。
该原则更进一步的应用时，领域类封装了与应用逻辑相关的信息和行为。窗口类相对简单，它们负责输入和输出，以及捕获GUI时间。但是并不文护应用数据或直接提供应用逻辑。
模型—视图分离的动机包括：
支持内聚的模型定义，这些定义只关注领域过程，而不是用户界面。
允许对模型和用户界面层分别进行开发。
使界面的需求变更对领域层的影响最小化。
允许新视图能够被方便地连接到现有的领域层智商，而不会对领域层产生影响。
允许对同一模型对象同时使用多个视图。
允许模型层的运行不依赖于用户界面层。
允许简模型层能够简便地一直到另一用户接口框架下。
4.5.1微波炉模型的逻辑架构和包图
通过着眼于领域模型，可获取对领域层类名的灵感。根据模型—视图分离原则，可得到微波炉的逻辑架构包图如下：
图4-8 微波炉模型系统的UML包图
4.6识别责任
基于GRASP和GoF等模式考虑，对领域模型进行分析，以确定责任。
4.6.1根据发布—预定模式进行设计
在本方案中，不仅使用了面向对象设计的两个基本原则：封装原则和委托原则，同时还是用了抽象，把接口与现实相分离，并用模式进行设计。
微波炉的部件之间存在一定的相互依赖关系，例如：
图4-9 取消/暂停按键与鸣叫器、定时器间的依赖
消除这种相互影响的一种方法是使用“发布—订阅”模式。这种模式有一个优点，即它把实现与接口进行了分离。该模式引入了目标对象和一组观察者的思想。实际上，观察者是一个借口，它使目标依附于接口的实现。
目标类是对象的模板或定义，一些其他的对象表示有兴趣要知道它能产生的事件。这些感兴趣的对象是观察者。与其对每个观察者副本，我们不如允许观察者通过预定目标指出其兴趣，当目标决定要对事件发信号时，它利用已预订观察者的列表，把时间通知给他们。由于案例是基于C#程序设计语言开发，而C#对事件的发布和订阅提供了良好的支持。
图4-10 发布—预定模式
根据此模式，最后得到四个具有高度复用性的包。
图4-11 包含类按钮和类ButtonPressListener的包Button
图4-12 包含类Door和类Door的事件监听接口的包Door
图4-13 包含类Timer和类Timer的事件监听接口的包Timer
图4-14 包含类PowerTube和类PowerTube的事件监听接口的包PowerTube
4.6.2根据适配器模式进行设计
在适配器模式中引入类，它能把产生的消息转换成能由打算的接受者处理的形式。这样的类的实例放在发送者和打算的接受者之间，以映射消息。
图4-15 适配器模式
在本案例中，为了解决问题，我们要把继承、委托和适配器模式结合起来使用。
4.6.3根据单实例类模式进行设计
通过对领域模型进行分析，我们知道仅有一个必须构建的微波炉，同样，微波炉的内部器件也只需要构建一份实例，因此我们采用单实例类的设计模式。
4.6.4设计类的CRC卡
上一页 [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] ... 下一页 >>