SalePayment与低耦合模式相关可以认为是低耦合模式在创建对象.PPTVIP

信息专家 (Information Expert) 为了计算合计需要哪些信息? SalesLineItem 与 Sale关联.而合计可以从SalesLineItem 的小计算出。 因此Sale是信息专家 结束了吗? 信息专家 (Information Expert)(cont) 谁负责计算SalesLineItem的小计? 需要的信息: SalesLineItem.quantity 和相关的ProductSpecification.price 根据信息专家模式，应该是SalesLineItem负责计算SalesLineItem的小计 类 职责 Sale 知道销售合计 SalesLineItem 知道明细小计 ProductSpecification 知道产品单价 信息专家 (Information Expert)(cont) 信息专家 (Information Expert) : 讨论 信息专家模式是对现实的模拟 DIY : Do It Yourself 信息专家 (Information Expert) : 优点 保证了封装性 对象使用他们自己的信息来完成职责。 支持低耦合，使得系统更为健壮，更易于维护 行为分布在拥有所需信息的类中 提倡定义内聚性更强的“轻量级”类，这样的类易于理解和维护。 通常支持高内聚 信息专家 (Information Expert):限制 在有些场合，由于高内聚和低耦合的要求，信息专家模式并不适用。 比如，谁应该将Sale存入DB? 控制器 问题: 系统事件应该由谁来处理? 解决方案: 将系统事件分配给下面的对象: 代表整个“系统”、“根对象” 的类。 代表用例场景的类，该事件就是场景中发生的一个事件 (use-case controller) 对于同一用例场景的所有系统事件使用相同的控制器类。 可以防止在UI层处理业务逻辑 控制器(cont) 系统事件 由外部产生的高层的事件 系统事件不是UI事件，不是像Window/View这样的对象。UI通过UI事件接受并组合为一个系统事件，将其委派给控制器完成。 由系统操作来执行 系统事件 系统事件 控制器: Example 在行为分析的过程中（比如系统顺序图），系统操作被识别出来，并赋给 System对象。 然而，这并不是说该事件将由名为System的对象处理。 究竟谁处理这个事件是在设计时引入的控制器对象时分配的。 System endSale() enterItem() makePayment() ….. 控制器: Example (cont) 谁来处理登录商品的事件？ 由系统本身来处理 :Register 由用例处理器来处理 :ProcessSaleHandler 如何选择由其他因素决定: 耦合 内聚 控制器: Example (cont) 确定系统事件应该分配给一个还是多个控制器 第一类控制器：Fa?ade Controller 表示整个系统 例: Register, RetailInformationSystem, Switch, Router, NetworkInterfaceCard etc. 适用于下面情况 只有较少的系统事件 第二类控制器：Use Case Controller 某个特定用例的所有事件操作定义在同一个用例控制器中。 适用于： 不将操作分离将会违背耦合和内聚的原则（例如：臃肿的控制器） 拥有跨越不同子系统的大量事件。 实例 public class EnterItemAction extends Action{ public ActionForward execute( ActionMapping mapping， ActionForm form...){ Repository repository = .....; Register register = repository.getRegister(); String txtId = ((SaleForm)form).getItemID(); String txtQty = ((SaleForm)form).getQuantity(); ItemID id = Transformer.toItemID(txtID); int qty = Transformer.toInt(txtQty); register.enterItem(id,qty); } } 控制器:优点 增加了可复用的构件和插拔的潜力。 是将表示层和业务层分离的方法 能够把握用例的状态 保证系统操作是以一种合法的顺