《计算机科学与工程系模式与对象设计课件.ppt》由会员分享，可在线阅读，更多相关《计算机科学与工程系模式与对象设计课件.ppt（128页珍藏版）》请在三一办公上搜索。
1、第7讲. 模式与对象设计,2019-8-17,2,内容,责任分配设计模式GRASP模式案例,谢谢观赏,2019-8-17,3,1.1引言,我们已经创建了领域模型确定有什么样的方法，属于谁，对象之间如何交互，这是开发面向对象系统的核心但是如何做?,谢谢观赏,2019-8-17,4,GRASP模式是帮助我们理解详细的原则和所需要的思考方法的学习工具这些模式与如何将责任分配给类相关,谢谢观赏,2019-8-17,5,1.2责任和方法,责任：分类器的契约和责任对象具有责任意味着:自己做某些事情，例如创建一个对象或者进行一个计算控制或者协调其它对象的活动“一个sale对象负责创建SalesLineIte
2、ms( a doing)”要想知道一个对象的责任,需要:知道私有的封装的数据知道相关的对象知道可以派生或者计算的对象“一个sale对象需要负责knowing its total”,谢谢观赏,2019-8-17,6,责任不等同于方法，但是方法是用来完成责任的Sale 类可以定义一个或多个方法来计算总价被命名为 getTotal的方法或者发送getSubTotal 消息给每一个SalesLineItem 对象，来获取每一个类别的价格,谢谢观赏,2019-8-17,7,1.3责任和交互图,责任可以通过编程实现或者可以用过创建交互图来进行分配,: Sale,makePayment(cashTender
3、ed),: Payment,create(cashTendered),implies Sale objects have a,responsibility to create Payments,谢谢观赏,2. 模式,2019-8-17,9,2.1学习的模式,在我们人类社会中，许多方面的成功经验都可以归结为模式事实上，教育的重要目标就是把学习的模式从一代传向下一代下面，我们将探索如何依据模式来学习下棋学习开发高质量的软件与学习下棋非常类似虽然失败的后果通常没有那么戏剧性,谢谢观赏,2019-8-17,10,2.2 成为下棋大师,首先学习规则和物理需求例如，棋子的名字，合法的移动，棋盘的构成，等等
4、然后，学习原则例如，每一个棋子的大小，如何将，如何吃子等等但是，要成为高手，还必须从其它人的棋谱中学习这些棋谱包含了许多必须理解，记忆和不断运用的模式这种棋谱也是非常多的,谢谢观赏,2019-8-17,11,2.3成为一个软件设计大师,首先学习规则例如，算法，数据结构和软件语言然后学习原则例如，结构化编码，模块化编码，面向对象编码，遗传编码等等但是， 为了真正掌握软件设计，还必须学习其它大师的设计 这些设计包含了必须理解，记忆和重复运用的模式这种模式也是非常多的,谢谢观赏,2019-8-17,12,2.4例子,模式名字: 信息专家（Information Expert）解决方案: 将责任分配给
5、拥有信息完成责任的类解决的问题: 将责任分配给对象的基本原则是什么？,最简单的，模式是一个命名的问题/解决对，它可以用在新的场景中，并包含了如何利用它解决新问题和对它在不同情况下的权衡讨论,谢谢观赏,2019-8-17,13,2.5优点,模式对专家的知识和设计中的优缺点进行了显示获取，并尽力使这种专家知识被广泛应用模式可以改进开发者之间的沟通模式名字构成一个词汇集模式有助于面向对象技术的推广,谢谢观赏,2019-8-17,14,2.6注意点,不要把所有的东西都作为一个模式 开发战略性的领域模式，并重用现存的战术型模式模式作者，应用开发者和领域专家之间的密切合作在文档中清楚表明何时可以应用，何时
6、不可以应用,谢谢观赏,3. GRASP,分配责任的通用原则模式Patterns of General Principles in Assigning Responsibilities,2019-8-17,16,3.1为什么&是什么,为什么在对象设计中，对责任的合理分配非常重要对责任进行分配一般是在画交互图，在编码时创建模式是一个命名的问题/求解对，它包含了好的建议和原则，这些与责任的分配相关是什么通用的责任分配软件模式（General Responsibility Assignment Software Patterns）,谢谢观赏,2019-8-17,17,3.2五个重要模式,信息专家（In
7、formation Expert）创建者（Creator）高度内聚（High Cohesion）低耦合（Low Coupling）控制器（Controller）,谢谢观赏,3.3.1模式1: 信息专家,2019-8-17,19,解决方案,将责任分配给信息专家，所谓的信息专家是拥有完成责任的信息的类,谢谢观赏,2019-8-17,20,问题,设计模型可能定义成百上千个软件对象，一个应用中也可能需要将成百上千项责任进行分配目的: 易于理解，维护，扩展和重用,谢谢观赏,2019-8-17,21,例子,NextGEN POS 应用，某些类需要知道销售总额谁负责知道销售总额?拥有需要的信息的对象类确定总
8、额需要回答的问题我们已经有领域模型了，但是我们依然没有设计模型,谢谢观赏,2019-8-17,22,如果已经有设计模型，并且包含了相关的类，首先关注它们否则，在领域模型中，分析如何依据领域模型中的表示来创建相应的设计类,谢谢观赏,2019-8-17,23,部分领域模型,谢谢观赏,2019-8-17,24,谢谢观赏,2019-8-17,25,Sale,date,time,getTotal(),SalesLineItem,quantity,getSubtotal(),New method,1 *: st := getSubtotal(),: Sale,t := getTotal(),*,:Sale
9、sLineItem,:SalesLineItem,谢谢观赏,2019-8-17,26,Sale,date,time,getTotal(),SalesLineItem,quantity,getSubtotal(),Product,Specification,description,price,itemID,getPrice(),New method,:Product,Specification,1.1: p := getPrice(),1 *: st := getSubtotal(),: Sale,t := getTotal(),*,:SalesLineItem,:SalesLineItem,谢
10、谢观赏,2019-8-17,27,这些责任在画交互图时被考虑和确定,谢谢观赏,2019-8-17,28,讨论,由于它们知道信息，所以对象必须做事情当信息分布在不同的对象中，他们需要相互间通过消息进行交互以分担工作在真实的世界中，对象可能没有生命的，但是在软件中，对象是“活着的”或者“有生命的”，因为它们将承担责任,谢谢观赏,2019-8-17,29,禁忌,没有万能药专家模式可能在某些情况中造成耦合和内聚例如，将Sale保存在数据库我们需要将与数据库处理相关的逻辑作为Sale的责任吗? 如果这样的话，我们将违反基本的结构原则：依据分离的主要的系统关注点进行设计将应用逻辑放在一个地方，将数据库逻辑
11、放在另外一个地方 (持久化服务子系统),谢谢观赏,2019-8-17,30,优点,实现了信息封装，因为对象使用它们自己的信息完成任务行为分布在拥有所需要的信息的类上,谢谢观赏,3.3.2模式2: 创建者（Creator）,2019-8-17,32,解决方案,将创建类A的实例的责任分配给类B，如果一个或多个下面的条件为真:B 聚合了（aggregates） A 对象B包含了（contains）A对象B记录了（records）A对象的实例B密切使用（closely uses）A对象B拥有传递给创建A所需要的初始化数据 ( 因此B是创建A的专家)B是A对象的创建者,谢谢观赏,2019-8-17,33
12、,问题,谁来负责创建某些类的新实例?在面向对象系统中对象的创建是一个最普通的活动我们需要一个分配创建责任的通用原则,谢谢观赏,2019-8-17,34,例子,在POS应用，谁需要负责创建 SalesLineItem 实例呢?,谢谢观赏,2019-8-17,35,sale包含了许多SalesLineItem 对象,: Register,: Sale,makeLineItem(quantity),: SalesLineItem,create(quantity),谢谢观赏,2019-8-17,36,讨论,某些时候创建者是通过查找具有在创建时传递的初始化数据的类而发现的例如，假设Payment 的一个
13、实例需要被初始化，在创建时，需要携带 Sale 总额信息. 由于Sale 知道总价, Sale 是Payment的备选创建者对象,谢谢观赏,2019-8-17,37,禁忌,许多时候，创建过程有很强的复杂性，例如由于性能原因需要回收实例，依据外部属性值有条件的创建一族相近似的类的一个实例建议采用Factory类,谢谢观赏,2019-8-17,38,优点,低耦合因为通过该模式存在的关联得到了满足,谢谢观赏,3.3.3低耦合,2019-8-17,40,解决方案,分配责任使得耦合度比较低,谢谢观赏,2019-8-17,41,问题,耦合是对一个元素与其他元素的连接，拥有知识，依赖等关系的强烈程度的度量高
14、耦合造成:相关的类的修改造成本地修改难以理解难以重用,谢谢观赏,2019-8-17,42,例子,我们需要创建一个Payment 实例并将其与Sale关联.,谢谢观赏,2019-8-17,43,方案1 (From the creator pattern),: Register,p : Payment,:Sale,makePayment(),1: create(),2: addPayment(p),谢谢观赏,2019-8-17,44,方案2,谢谢观赏,2019-8-17,45,讨论,低耦合是一个在设计中时时需要记住的原则；它也是需要一直考虑的目标。这是设计者用来评估设计决策时运用的一个评价准则.但
15、是我们知道O-O 软件是一个协同系统. 这意味着对象之间从某种程度上都是耦合的.因此，这是一个我们尽力去满足的原则，而不必一定遵循.,谢谢观赏,2019-8-17,46,禁忌,对稳定的元素和普遍的元素的高耦合一般不是一个问题例如，一个Java J2EE应用对 Java库 (java.util, 等等）的耦合没有问题, 因为它们是稳定的，并被普遍使用,谢谢观赏,2019-8-17,47,优点,其他组件中的变更不会造成影响由于分离，便于理解方便重用,谢谢观赏,3.3.4高内聚,2019-8-17,49,解决方案,责任分配以保证高内聚,谢谢观赏,2019-8-17,50,问题,内聚是对一个元素的责任
16、之间的关系是否密切相关和集中的度量低内聚的类包含了很多无关的事情，或者承担了太多的工作。它们有下面这些的问题:难以理解难以重用难以维护脆弱; 常常受修改影响,谢谢观赏,2019-8-17,51,例子,我们需要创建(cash) Payment 的实例并将它与Sale 关联解决方案1,谢谢观赏,2019-8-17,52,解决方案2,谢谢观赏,2019-8-17,53,讨论,这是一个需要放在心中的模式，就如同低耦合模式一样高度内聚的类一般具有较少的方法，具有高度相关的功能，而且不完成太多的工作,谢谢观赏,2019-8-17,54,模块化设计,一些老的原则依旧很重要耦合内聚模块设计“模块化是系统的一个
17、属性，该系统被分解成一组内聚和松耦合的模块”,谢谢观赏,2019-8-17,55,内聚和耦合-:软件工程的“阴”和“阳”,谢谢观赏,2019-8-17,56,不要教条,低耦合在某些情况下是可以接受的将SQL语句放入每一个类遵循了内聚模式. 但是将SQL语句分离出来并归并在一个类中更合理，因为它需要特殊的技术在分布应用中，为了改进性能，我们可以设置一个远程操作 setData 而不是分别设置 setName, setSalary 和 setHireDate.,谢谢观赏,3.3.5控制器（Controller）,2019-8-17,58,解决方案,将接收和处理系统事件消息的责任分配给代表下列方面的
18、类:代表整个系统，设备或子系统代表一个与系统事件相对应的用例场景,谢谢观赏,2019-8-17,59,问题,谁应该为处理输入系统事件负责?一个控制器是一个没有用户界面的对象，负责接收和处理系统事件。控制器定义了系统操作的方法,谢谢观赏,2019-8-17,60,例子,在NextGen应用中，有下列几个系统操作,谢谢观赏,2019-8-17,61,actionPerformed( actionEvent ),: ?,: Cashier,:SaleJFrame,presses button,enterItem(itemID, qty),Interface,Layer,Domain,Layer,sy
19、stem event message,哪一个类对象需要负责接收系统事件消息？有时被称为控制器或者协调器。它一般不工作而是将消息在分配给其他对象。控制器是一种从接口层到领域层的“方面”,谢谢观赏,2019-8-17,62,谢谢观赏,2019-8-17,63,讨论,可以使用同一个控制类来处理一个用例中的所有系统事件以维护控制器中有关用例状态的信息 一般，控制器将需要完成的工作分配给其他对象；它负责协调或者控制活动，自己不做太多工作。,谢谢观赏,2019-8-17,64,方面控制器（Facade Controller）它代表了整个系统，设备或一个子系统它提供了从UI层往其他层的服务调用的主要入口 对
20、整个物理单元的抽象，例如Register, TelecommSwitch, Phone 或 Robot代表了整个软件系统的类，例如POSSystem设计者选择用来表示整个系统，子系统的其他概念，例如如果是一个游戏软件，选择ChessGame,谢谢观赏,2019-8-17,65,用例控制器对每一个用例设置一个单独的控制器这是支持系统的人工结构例如，在NextGen应用中，例如Process Sale 等用例可以与 ProcessSaleHandler 类关联什么时候我们选择用例控制器?当有太多的系统事件并设计不同的过程，用例控制器是一个好的选择。它将处理它们的任务分配给那些可管理的单独的类，也提
21、供了一个获知和推理目前进行中的场景的当前状态的基础。,谢谢观赏,2019-8-17,66,Register,.,endSale(),enterItem(),makeNewSale(),makePayment(),makeNewReturn(),enterReturnItem(),. . .,System,endSale(),enterItem(),makeNewSale(),makePayment(),makeNewReturn(),enterReturnItem(),. . .,system operations,discovered during system,behavior analy
22、sis,allocation of system,operations during design,using one facade controller,ProcessSale,Handler,.,endSale(),enterItem(),makeNewSale(),makePayment(),System,endSale(),enterItem(),makeNewSale(),makePayment(),enterReturnItem(),makeNewReturn(),. . .,allocation of system,operations during design,using s
23、everal use case,controllers,HandleReturns,Handler,.,enterReturnItem(),makeNewReturn(),. . .,谢谢观赏,2019-8-17,67,在统一过程中：边界对象（Boundary Objects） 是接口的抽象实体对象（Entity Objects） 是独立于应用（经常是持久性）领域软件对象控制对象（Control Objects） 是控制器模式中描述的用例处理器,谢谢观赏,2019-8-17,68,优点,提高了重用的可能性，提供了可插拔的接口-它保证了接口层不处理应用逻辑对用例的状态进行推理保证系统操作以合法的
24、顺序发生,谢谢观赏,2019-8-17,69,问题和解决方案,“浮肿的”控制器（Bloated Controllers）如果设计得不合理，控制类内聚性不强-不聚焦并处理了太多领域的责任症兆一个控制类接收所有的系统事件控制类自己处理了完成系统事件所需要的太多任务控制器有太多的属性并维持了系统或领域的信息,谢谢观赏,2019-8-17,70,接口层并不处理系统事件,谢谢观赏,2019-8-17,71,Cashier,:SaleJFrame,actionPerformed( actionEvent ),:Sale,1: makeLineItem(itemID, qty),Interface Laye
25、r,Domain Layer,对于接口层的对象而言，例如Window参与决定如何处理领域过程业务逻辑是嵌入在表现层中的，而该层并不十分有用,SaleJFrame 不能发送该消息,presses button,谢谢观赏,4. 使用GRASP模式实现Use-Case,2019-8-17,73,4.1目标,设计用例的实现运用GRASP模式给类分配责任使用UML交互图标记来表示对象设计责任的分配和协作的设计是非常重要的，并且是设计，画图或者编程中具有创新性的步骤我们将试图说明软件设计是工程而不是艺术,谢谢观赏,2019-8-17,74,4.2 用例实现,用例实现 描述了一个特定的用例在设计模型中是如何
26、通过协作的对象来实现的.UML交互图是一种表示用例实现的通用的语言,谢谢观赏,2019-8-17,75,谢谢观赏,2019-8-17,76,协同图（Collaboration Diagrams） 可以用于显示用例实现,谢谢观赏,2019-8-17,77,顺序图,谢谢观赏,2019-8-17,78,or,谢谢观赏,2019-8-17,79,契约和用例实现有可能直接从用例的文字中设计用例实现 对某些系统操作而言，契约可以用于增加描述细节契约CO2: enterItemOperation: enterItem(ItemID: ItemID, quantity:integer)Cross Refere
27、nces: Use Cases: Process SalePreconditions: There is a sale underwayPostconditions: -A SalesLineItem instance sli was created (instance creation)-,谢谢观赏,2019-8-17,80,1: makeLineItem(.),enterItem(id, qty),1.1: create(.),:Register,:Sale,:SalesLineItem,Satisfy the state change of SalesLineItem instance
28、creation,谢谢观赏,2019-8-17,81,领域模型和用例实现选择合适的责任分配依赖于领域模型但是用例实现可能引起领域模型的修改,谢谢观赏,2019-8-17,82,概念 vs. 设计类领域模型可以用以启发我们在设计模型中定义软件类并据此命名,谢谢观赏,2019-8-17,83,Payment,amount,Sale,date,time,Pays-for,Payment,amount: Money,getBalance(): Money,Sale,date: Date,startTime: Time,getTotal(): Money,. . .,Pays-for,UP Domain
29、 Model,Stakeholders view of the noteworthy concepts in the domain.,UP Design Model,The object developer has taken inspiration from the real-world domain in,creating software classes. Therefore, the representational gap between how,stakeholders conceive the domain, and its representation in software,
30、 has been,lowered.,1,1,1,1,inspires,objects,and,names in,conceptual,classes,design,classes,谢谢观赏,4.3NextGen 迭代的Use-Case实现,2019-8-17,85,4.3.1 对象设计: makeNewSale,makeNewSale 系统操作发生于当收银员在顾客到达后有东西要买，开始一笔新的买卖时,Contract CO1: makeNewSaleOperation: makeNewSale()Cross References: Use Cases: Process SalePrecond
31、itions: nonePostconditions: -A Sale instance s was created(instance creation) -s was associated with the Register (association formed) -Attributes of s were initialized,谢谢观赏,2019-8-17,86,选择一个控制类,依据控制者模式，下面是一些选择项:,Faade Controller,Use Case Controller,在设计模型中，该Register 是一个软件对象。它不是一个真实的物理的收银台，而是一种软件抽象，选
32、择这个名字可以减少领域和软件概念之间的表示鸿沟.,谢谢观赏,2019-8-17,87,在这个案例中，由于只有少数系统操作, Register 足够了,谢谢观赏,2019-8-17,88,创建新Sale,软件对象Sale 必须被创建: Creator 模式谁来创建它呢?Register : 创建它，然后与之关联当Sale 创建后，它必须创建一个空的集合，以记录所有的将来要被添加的 SalesLineItem 实例,谢谢观赏,2019-8-17,89,this activation is implied to be within the,constructor of the Sale instan
33、ce,谢谢观赏,2019-8-17,90,4.3.2 对象设计: enterItem,enterItem 系统操作发生于当收银员输入一个购买商品的itemID 和 (可选)数量.,Contract CO2: enterItemOperation: enterItem(itemID: ItemID, quantity: integer)Cross References: Use Cases: Process SalePreconditions: There is an underway sale.Postconditions: -A SalesLineItem instance sli was
34、created (instance creation) -sli was associated with the current Sale (association formed) -sli.quantity became quantity (attribute modification) -sli was associated with a ProductSpecification, based on itemID match (association formed),谢谢观赏,2019-8-17,91,选择控制类,系统操作消息enterItem的责任的处理如同makeNewSale一样，采
35、用Controller 模式继续使用Register 作为控制器,谢谢观赏,2019-8-17,92,显示商品描述和价格,使用的设计原则被称为模型-视图分离原则（Model-View Separation）, 即显示任务不应该是非GUI对象的责任尽管用例说明了在操作后描述和价格将被显示，但是设计中在此时将忽略此情况,谢谢观赏,2019-8-17,93,创建一个新的SalesLineItem,enterItem 契约的后置条件: 显示创建，初始化和与SalesLineItem的关联 在领域模型中，Sale 包含了SaleLineItem对象. 因而，软件Sale 也类似地包含软件 SalesLi
36、neItem.通过Creator模式, 软件Sale 是创建SalesLineItem的备选对象.,谢谢观赏,2019-8-17,94,通过将新的实例存放在商品条目集合中，Sale 可以与新创建的SalesLineItem 关联. 后置条件表明，当创建SalesLineItem 时，需要一个 数量值，所以，Register 需要将此值传递给Sale， Sale必须将此值作为create 消息的一个参数.,谢谢观赏,2019-8-17,95,寻找ProductSpecification,SalesLineItem 要与匹配进入的itemID 的ProductSpecification 建立关联
37、这意味着基于一个itemID 匹配，必须返回一个 ProductSpecification谁必须负责“基于一个itemID 匹配，必须返回一个 ProductSpecification ”?Creation模式?Controller模式?,谢谢观赏,2019-8-17,96,专家模式依据领域模型，ProductCatalog 逻辑上包含所有的ProductSpecifications我们可以设计一个ProductCatalog 对象负责该责任谁应该发送 getSpecification 消息给ProductCatalog 来请求ProductSpecification呢可以假设在启动用例的初始
38、化过程中，创建长生命周期的Register 和ProductCatalog 实例，并且Register 对象与ProductCatalog 对象之间存在永久关联，这样，可以让Register 给ProductCatalog 发送getProductDescription消息.,可见性: 一个对象“看见”或引用另一个对象的能力,谢谢观赏,2019-8-17,97,从数据库中检索ProductSpecification,不可能把所有 ProductSpecification 全部放在内存中但是可以把它们放在关系数据库或者对象数据库中，然后按需检索为了简单起见，从数据库中检索的问题稍后讨论,谢谢观赏
39、,2019-8-17,98,谢谢观赏,2019-8-17,99,4.3.3. 对象设计: endSale,当收银员按下表示商品条目输入完毕的按钮后，将会产生endSale 系统操作,Contract CO3: endSaleOperation: endSale()Cross References: Use Cases: Process SalePreconditions: There is an underway sale.Postconditions: -Sale.isComplete became true (attribute modification),谢谢观赏,2019-8-17,1
40、00,选择控制类,继续使用Register 作为控制器,谢谢观赏,2019-8-17,101,设置Sale.isComplete 属性,除非是控制器或者创建问题，否则信息专家模式应该是我们首先考虑的模式谁应该负责将Sale的属性 isComplete 设置为true呢?根据信息专家模式, 应该是由Sale 本身完成.,:Register,endSale(),s :Sale,1: becomeComplete(),by Expert,by Controller,谢谢观赏,2019-8-17,102,UML 表示约束，注释和算法的方法,有些时候在UML中，我们希望用文字来描述方法中的算法，或者指定
41、某些约束约束: semantically meaningfully information attached to a model elementNote: is a comment that has no semantic impact,谢谢观赏,2019-8-17,103,计算销售总额,依据模型视图分离的设计原则，我们现在不应该关注如何显示销售总额，而是必须保证如何知道销售总额除非是控制器或者创建问题，否则信息专家模式应该是我们首先要考虑应用的模式,考虑处理销售的如下片断主成功场景:1. Customer arrives2. Cashier tells system to create a
42、 new sale3. Cashier enters item identifier4. System records sale line item and Cashier repeats steps 3-4 until indicates done5. System presents total with taxes calculated,谢谢观赏,2019-8-17,104,谢谢观赏,2019-8-17,105,The Sale-getTotal Design,并不是每一个交互图都由系统操作消息开始，可以由设计者希望表示其交互的任何消息开始,谢谢观赏,2019-8-17,106,:Sale
43、,tot := getTotal(),1 *: st := getSubtotal(),:ProductSpecification,1.1: pr := getPrice(),: SalesLineItem,*, st = aSLI.quantity * aSLI.prodSpec.price ,/ observe the seudo code style here,public void getTotal(),int tot = 0;,for each SalesLineItem, sli,tot = tot + sli.getSubtotal();,return tot,Note the
44、semi-formal style of the constraint. aSLI is not,formally defined, but most developers will reasonably,understand this to mean an instance of SalesLineItem.,Likewise with the expression aSLI.prodSpec.price.,The point is that the constraint language can be informal,to support quick and easy writing,
45、if desired.,谢谢观赏,2019-8-17,107,4.3.4 对象设计: makePayment,当收银员输入所支付的现金数额后，将发生makePayment 系统操作,Contract CO4: makePaymentOperation: makePayment(amount: Money)Cross References: Use Cases: Process SalePreconditions: There is an underway sale.Postconditions: -A Payment instance p was created (instance creat
46、ion) -p.amountTendered became amount( attribute modification) -p was associated with current Sale (association formed) -The current Sale was associated with the Store (association formed); (to add it to the historical log of completed sale),谢谢观赏,2019-8-17,108,创建Payment,创建了Payment 的实例p (创建实例)这是一个创建职责
47、.两个候选者:RegisterIn real domain a register records account informationThe Register is the controller which receives the system operation makePayment messageSalesale 对象频繁使用Payment,?,谢谢观赏,2019-8-17,109,当存在多个可选设计时，应更深入地观察可选设计所存在的内聚和耦合，以及未来可能存在的进化压力。选择具有良好内聚，耦合和在未来变化时能保持稳定的设计,1: makePayment(cashTendered),
48、1.1: create(cashTendered),:Register,:Sale,:Payment,makePayment(cashTendered),by Controller,by Creator and Low Coupling,谢谢观赏,2019-8-17,110,记录Sale的日志,Store,.,addSale(s : Sale),.,SalesLedger,.,addSale(s : Sale),.,Store is responsible for,knowing and adding,completed Sales.,Acceptable in early,developme
49、nt cycles if the,Store has few,responsibilities.,SalesLedger is responsible,for knowing and adding,completed Sales.,Suitable when the design,grows and the Store,becomes uncohesive.,Sale,.,.,Sale,.,.,Logs-completed,5,Logs-completed,5,*,*,1,1,谢谢观赏,2019-8-17,111,1: makePayment(cashTendered),1.1: create
50、(cashTendered),:Register,s :Sale,:Payment,makePayment(cashTendered),:Store,2: addSale(s),completedSales: Sale,completedSales: Sale,2.1: add(s),by Expert,note that the Sale instance is named,s so that it can be referenced as a,parameter in messages 2 and 2.1,谢谢观赏,2019-8-17,112,计算余额,谁负责计算余额?PaymentSal
