第七讲对象设计-Read.ppt

信息专家-示例 问题：哪个类应当负责了解销售的总额？ 按照信息专家（Information Expert）的建议，我们应当寻找具有确定总额所需信息的那个对象类。 问题：我们要查看领域模型或设计模型来分析具有所需信息的类？ 答案：如果在设计模型中存在相关的类，首先查看设计模型；否则查看领域模型，并尝试利用（或扩充）它的表示，以激发相应设计类的创建 信息专家-示例 :Sale t=getTotal 新方法 Sale Time …… getTotal() 信息专家-示例 :Sale t=getTotal 新方法 Sale time …… getTotal() Lineitems[i] SalesLineitem 1*:st=getSubtotal SalesLineItem quantity getSubtotal() 这种表示法指明我们将遍历集合中的所有元素 信息专家-示例 :Sale t=getTotal Lineitems[i] SalesLineitem 1*:st=getSubtotal Product Description 1.1:p:=getPrice() Sale time …… getTotal() SalesLineItem quantity getSubtotal() 新方法 Product Description description price itemID getPrice() 信息专家-示例 设计类 职责 Sale 知道销售的总额 SalesLineItem 知道商品的小计 ProductDescription 知道产品的价格 信息专家-示例 :Register :Sale p:Payment makePayment() 1:create() 2:addPayment(P) 信息专家-示例 :Register :Payment :Sale makePayment() 1:makePayment() 1.1.create() 信息专家-示例 :Register :ProcessSaleHandler enterItem(id,quantity) enterItem(id,quantity) 控制器的选择 信息专家-示例 :Register :Payment mackPayment() create() addPayment(p) :Sale Register 创建Payment 信息专家-示例 :Register :Payment mackPayment() create() :Sale mackPayment() GRASP之三低耦合 问题： 怎样降低依赖性，减少变化带来的影响，提高重用性？ 耦合是对某元素之间的连接、感知和依赖程度的度量。具有低（或弱）耦合的元素不会包括类、子系统、系统等 具有高（或强）耦合的类依赖于许多其他的类，这样的类或许不是我们所需要的。有些类会遇到以下问题： 由于相关类的变化而导致本体的被迫变化 难以单独地理解 由于使用高耦合类时需要它所依赖的类，因此很难重用 低耦合 名称：低耦合（Low Coupling） 问题：如何减少因变化产生的影响？ 解决方案： 分配职责以使（不必要的）耦合保持在较低的水平。利用这一原则来评估可选方案 GRASP之四高内聚 问题： 怎样保持对象是有重点的、可理解的、可管理的，并且能够支持低耦合？ 从对象设计的角度上说，内聚（或更为专业地说，是功能内聚）是对元素职责的相关性和集中度的度量。如果元素具有高度相关的职责，而且没有过多工作，那么该元素具有高内聚性。这些元素包括类、子系统等等。 高内聚 名称：高内聚（High Cohesion） 问题：怎样使对象保持有内聚、可理解性和可管理性，同时具有支持低耦合的附加作用？ 解决方案： 职责分配应保持高内聚，依此来评估备选方案。 在实践中，内聚程度不能脱离其他职责及其他原则（如专家和低耦合）单独地考虑 GRASP之五控制器 根据MVS原则，我们知道UI对象不应当包含应用逻辑或业务逻辑。因此，一旦UI对象获得了鼠标等事件，它们应该把该请求委派给领域层的领域对象 问题： 在UI 层之上首先接收和协调（控制）系统操作的第一个对象是什么？ 在SSD分析期间，要首先探讨系统操作。这些是我们系统的主要输入事件。例如，当使用POS终端的收银员按下“结束销售”按钮时，他就发起了表示“销售已经终止”的系统事件。类似地，当使用文字处理器的书写者按下“拼写检查”按钮时，他就发起了表示“执行拼写检查”的系统事件 控制器是UI层之上的第一个对象，它负责接收和处理系统操作消息 控制器 名称：控制器（Controller） 问题：在UI层