第17讲面向对象的设计模式.pptVIP

* 职责和方法 方法实现职责 * GRASP GRASP（General Responsibility Assignment Software Pattern，通用职责分配软件模式） GRASP模式描述了将职责分配给对象的基本原则，这些原则被表示成模式 专家（Expert）、创建者（Creator）、高内聚（High Cohesion）、低耦合（Low Coupling）、控制者（Controller） 多态（ Polymorphism）、纯虚构（ Pure Fabrication）、中介者（Indirection）、不要和陌生人讲话（Protected Variations） * GRASP：Expert模式 目的：将一个职责分配给信息专家—掌握了为履行职责所必需的信息的类 专家模式在职责分配中的应用比任何其他模式的应用都要广泛，它是面向对象的设计中的一个基本指导原则 专家不是一个含糊的或者新奇的概念，它表达出最普遍的一种“直觉”，即对象所能完成的工作要依赖于它所掌握的信息 优点： 封装能够得以维持，因为对象只使用他们自己包含的信息来完成任务（封装支持低耦合） 系统行为只分布在具有所需信息的类中（类具有高聚合度） 别名： 把责任交给数据；谁知道谁来干；拟人化；自己做… * 示例: Sale的总额 在销售点终端应用中,一些类需要知道一个Sale的总额。 根据专家模式，我们应该找出哪个类对象具有确定销售项总额所需要的信息。 确定销售项总额需要知道什么信息呢？ 必须要知道一个销售项对应的SalesLineItem实例。 只有一个Sale实例知道这些信息，因此，按照专家模式，Sale对象所在类应该履行这个职责， Sale就是信息专家 * 示例: Sale的总额 确定销售项记录的金额需要知道什么信息呢？ SalesLineItem.quantity和SalesLineItem.price是所需要的信息 SalesLineItem知道它的商品数量和相关的ProductSpecification 根据专家SalesLineItem应该确定记录的子金额(subtotal), SalesLineItem是信息专家。 * 示例: Sale的总额 为了知道和回答一个SalesLineItem的子金额，一个SalesLineItem需要知道商品价格。 因此ProductSpecification是一个信息专家，它可以回答商品价格。 * 示例: Sale的总额 新方法 新方法 * GRASP：Creator模式 目的：要找到一个与被创建对象之间有关联关系的创建者。 问题：谁负责创建一个类的新实例？ 优点：支持低耦合度。因为被创建的类很可能早已经对创建者类可见，耦合程序可能不会增加。 * GRASP：Creator模式 解决方案：将创建一个类A的实例的职责指派给类B的实例，如果下例条件满足的话： B聚集了A对象 B包含了A对象 B记录了A对象的实例 B要经常使用A对象 当A对象的实例被创建时，B具有要传递给A的初始化数据（也就是说B是创建A的实例这项任务的信息专家） B是A对象的创建者。 如果以上的条件中不止一条成立的话，最好让B聚集或者包含A。 * 示例：创建一个SalesLineItem 在销售点应用系统中，哪个类负责创建一个SalesLineItem的实例呢？ 根据创建者模式，找出一个类，该类聚集、包含SalesLineItem的实例。 由于Sale包含了多个SalesLineItem的实例对象，因此Sale是承担创建SalesLineItem实例这个任务的一个好的候选者。 在Sale中添加新方法makeLineItem()。 * GRASP： Controller模式 解决方案：将处理系统事件消息的职责分派给代表下列事物的类： 代表整个“系统的类”（虚包控制者） 代表整个企业或组织的类（虚包控制者） 代表真实世界中参与职责（角色控制者）的主动对象类 代表一个用例中所有事件的人工处理者类，通常用“用例名处理者”的方式命名（用例控制者）。 使用同一个控制者类处理一个用例中的所有的事件。 问题：谁负责处理一个系统事件？ * GRASP： Controller模式 优点： 增加软件构件的可重用性。 理解用例的状态。 问题： 如果设计不好，一个控制者类可能会有低聚合度——功能不集中并且职责所涉及的领域太多，这个的控制者类被称为肥控制者。 警告：使用角色控制者可能会导致低劣的设计 * 示例： 哪个类对象应该是系统事件的控制者呢？ 代表整个“系统的类”（POST） 代表整个企业或组织的类（Store） 代表真实世界中参与职责的主动对象类（Cashier） 代表一个用例中所有事件的人工处理者类(BuyItemsHandler)。 * 示例：GRASP模式应