phpcms v9网站建设入门中山环保骏域网站建设专家

当前位置： 首页 > news >正文

phpcms v9网站建设入门,中山环保骏域网站建设专家,12380网站建设情况汇报,男女这样做那个网站GRASP设计原则介绍9种基本原则创建者 Creator问题解决方法何时不使用?好处信息专家 Information Expert问题解决方法信息怎么做优点低耦合 Low Coupling耦合问题解决方法原则何时不使用?控制器 Controller问题解决方法外观控制器会话控制器优点臃肿控制器的解决方法高内聚 Hi… GRASP设计原则介绍9种基本原则创建者 Creator问题解决方法何时不使用?好处信息专家 Information Expert问题解决方法信息怎么做优点低耦合 Low Coupling耦合问题解决方法原则何时不使用?控制器 Controller问题解决方法外观控制器会话控制器优点臃肿控制器的解决方法高内聚 High Cohesion问题解决办法用法衡量概念之间相关度的两个指标内聚的最佳实践类低内聚多态 Polymorphism问题解决办法推论纯虚构 Pure Fabrication问题解决办法推论原则风险间接 Indirection问题解决办法隔离变化问题解决办法变化点的分类介绍 GRASP(General Responsibility Assignment Software Pattern)是通用职责分配软件设计模式它可以帮助设计人员理解面向对象设计的本质并以一种有条理的、理性的、可解释的方式来运用这些原则。由《UML和模式应用》(Applying UML and Patterns)一书作者Craig Larman提出。 在面向对象设计的过程中一般的通用方式是构思对象的职责、角色和协作。通常来说我们在编码过程中先分析问题域从中抽象出对象解决问题。简单的面向对象和优秀的面向对象设计的区别在于如何更合理的划分对象的角色给对象赋予合理的职责以及对象之间的交互关系。 GRASP是对象职责分配的基本原则其核心思想是职责分配用职责设计对象。 9种基本原则 创建者Creator信息专家Information Expert低耦合Low coupling控制器Controller高内聚High Cohesion多态性Polymorphism纯虚构Pure Fabrication间接性Indirection隔离变化Protected Variations 这些模式都是针对软件开发上的一些问题进行解决。发明这些技巧不是为了要创造新的工作方式而是为在面向对象设计上对经过测试的程序设计方式创建文档并且标准化。 Craig Larman提到“软件开发最关键的设计工具不是UML或其他的技术是明了设计原则的心智。”。因此GRASP原则是心理层面的工具集是面向对象软件设计学习的辅助工具。 创建者 Creator 问题 谁负责创建类的实例 解决方法 满足下面一个选项则由B来创建A B包含聚集AB记录AB紧密使用 AB拥有A的初始化数据 若有一个以上的选项适用则首选包含或聚集A的类。 注意A和B都是软件对象而不是领域对象。 何时不使用? 出于性能目的缓存而重用类的实例有些情况下要基于某些外部属性值从一个相似类的家族创建一个实例抽象工厂模式委托职责向下传递其他复杂情况 好处 使用方便高内聚低耦合 信息专家 Information Expert 问题 为一个对象分配职责的一般性原则是什么 解决方法 若这个类拥有完成这个职责所需要的数据则把这个职责分配给这个类。 信息 一个对象拥有的状态和一个对象相关的其他对象一个对象派生的信息等等 怎么做 明确地表达职责在设计模型中查看相关的类在领域模型中查看并创建设计类 优点 封装性对象充分利用自身的信息低耦合 系统行为分布到不同的类高内聚 低耦合 Low Coupling 耦合 耦合的定义 一个元素和另一个元素的连接感知和依赖程度。 比较 内聚模块内的元素之间紧密程度如一个类内部操作之间。 耦合两个子模块之间的紧密程度如两个类之间的操作。 高耦合带来的问题 牵一发动全身元素孤立是无法理解元素很难重用 X与Y存在耦合的情况例如 X拥有Y的属性X调用Y的服务X有Y的成员变量方法参数和局部变量X是Y的子类Y是接口X实现接口 问题 如何保证设计方案支持低依赖性低变化影响度和增加可重用性 解决方法 分配职责后仍然保持低耦合。 原则 低耦合不具备可操作性是一个评估原则如若两个方案都可以的倾向于选择低耦合的方案。继承关系中子类与父类的耦合非常紧密如能用组合的不要用继承。类之间存在适当的耦合是必须的正常的。因为只有这样才产生面向对象系统任务才能通过对象间的相互协作来完成。不能单独考虑低耦合极端情况类之间没有耦合。这样会形成一个很差的设计一个类来完成全部的工作。低耦合与其他原则如信息专家、高内聚必须综合考虑。 何时不使用? 若是稳定的或广为流传的可以有高耦合如Java的jdk软件系统可以和jdk高耦合。 控制器 Controller 问题 在领域层由谁负责首先接收并协调来自UI层的系统操作 解决方法 Facade(外观) Controller代表整个系统的对象如一个根对象一个系统运行的设备或一个主要的子系统。Use Case or Session Controller用例控制器、会话控制器代表一类系统事件产生的用例场景。 外观控制器 相当于领域层对外部世界的“脸”。适用于 相对较小的系统有限数量的系统操作在消息处理系统中不能转发消息到可选的控制器时 会话控制器 处理系统某个明确的功能集比如相关的一组系统事件。适用于 当采用外观控制器会导致高耦合、低内聚时很多系统事件跨越多个不同的处理过程概念上容易理解和构建 其命名习惯 Handler 、 CoOrdinator、Session 优点 容易适应UI层的变化领域层代码易于重用因为UI层一般与应用关系密切有助于保证应用所需要的操作顺序可以对系统的状态进行推理UI层不保存系统状态 臃肿控制器的解决方法 当一个控制器处理了大部分系统事件时控制器掌握了太多的系统信息就会形成臃肿的控制器导致低内聚。解决方法是 增加更多的控制器采用会话控制器替换外观控制器控制器委托任务给别的对象而不是自己做高内聚的理念 高内聚 High Cohesion 问题 如何使对象功能专注、可理解、可管理同时又支持低耦合。 解决办法 分配职责时保证高内聚。 用法 用作评价工具更多的是一种理念没有具体的可操作原则。 衡量概念之间相关度的两个指标 Cohension内聚模块内元素之间联系紧密的程度例如一个类内部的操作之间。Coupling耦合两个模块之间联系的强度。 内聚的最佳实践 1 一个类完成的功能不要太多且这些功能都是同级别的。例如教授的主要功能是教学研究员的主要工作是科研。 2 如果同类别的工作太多则会定义新的类分担任务相互间合作。 例如”不是一家人不进一家门”“人”指的是操作职责”门”指的是模块类。 类低内聚 症状 做了太多相互无关的工作不是你的职责你做了。做了太多工作是你的职责但做的事情太多了需要把职责在细分。 原因 大粒度的抽象如打扫卫生可以分为扫地擦黑板等。做了太多本应该委托给其他类去做的工作。 缺点 难以理解因为职责太多太复杂。难以重用耦合度太高。难以维护很难修改。没有稳定的时刻总是在修改 (通常都会高耦合)。 多态 Polymorphism 问题 如何处理因类型不同而导致行为不同的一类需求 解决办法 使用多态操作为依据类型变化的行为来分配职责。 推论 不要测试对象的类型或条件逻辑并以此选择相应的行为。即不要使用条件逻辑而是为不同的类定义相同名字的方法。不同的类实现相同的接口或有一个共同的父类继承。 纯虚构 Pure Fabrication 问题 依据一些原则比如信息专家获得的解决方案不合适的情况下既不想违反低耦合、高内聚也不想违反其他的原则如何把职责分配给对象 解决办法 把高度内聚的职责分配给虚构出来的一个类这个类在领域模型里没有对应的概念。 推论 这种方式在有的场合能起到支持低耦合、高内聚、重用的效果。 原则 使用虚构类仍然保持低耦合、高内聚但可重用性要增加。多数情况下是按照功能来定义新的类是一种“功能为中心”的对象如果功能相关性比较高则满足高内聚的特性。 风险 宽泛地说虚构对象分为两类代表性概念为主的分解和行为性概念为主的分解可能导致面向功能或者面向过程的分析/设计然后用OO语言去实现。 间接 Indirection 问题 若两个对象直接连接导致耦合太紧如何解决 即把职责分配到哪里可以避免两个或多个对象之间的直接耦合如何解耦对象以保持较高的可重用性 解决办法 把职责分配给一个中介对象隔离对象使两个对象、构件或服务之间不产生直接耦合。 因为中介对象有一种特殊的作用一般对象与中间对象之间直接耦合相对比较简单。 与纯虚构类似但目的不同。 隔离变化 问题 如何设计对象、系统和子系统使得这些成分里面的变化因素、不稳定因素不会对系统的其余部分造成意想不到的影响 即需求一定会变化的如何做到以系统的局部变化为代价就可以应对这一点 解决办法 标识出能够已知或预计的变化点或者不稳定点职责分配的时候创建一个稳定的接口把它们与系统的其余部分隔离开来。 注意“隔离可能的变化”是一个设计原则如下技巧都使用隔离变化数据封装、多态、数据驱动设计、 服务查询、配置文件、接口等都是这种机制的不同体现。 变化点的分类 变化点当前系统已经存在。演化点当前系统不存在未来可能存在的变化。 GRASP原则是一种理念要时刻牢记随时使用就会造成潜移默化地加深理解从而得到更好的设计