GRASP(通用职责分配软件模式)介绍及一些小经验

类别:软件工程 点击:0 评论:0 推荐:
通用职责分配软件模式(GRASP)侧重于基本的通用设计过程,是针对FURPS+需求模型中的Functional(功能性)的重要的设计原则。 GoF设计模式更注重FURPS+需求模型中的质量需求的设计。 可以在GoF设计模式中找到GRASP的影子。


个人的一点小经验:
1、解决接口变化的外部服务问题时使用“适配器模式<-工厂模式(创建适配器)<-Singleton模式(使全局可见)”.
2、解决变化的算法及策略问题时(客户定制业务规则)使用“策略模式(将不同算法定义为实现同一接口的独立类)<-工厂模式(创建策略对象—)<-Singleton模式(可选)”,并可以加入组合模式来解决策略的冲突。
3、使用观察者模式降低表示层与业务层的耦合。


模式名称 描述(问题/解决方案) 信息专家模式 问题:对象设计和职责分配的一般原则是什么?

解决方案:将职责分配给拥有履行一个职责所必需信息的类--即信息专家。(也就是将职责分配给一个类,这个类必须拥有履行这个职责所需要的信息。) 创建者模式 问题:谁应该负责产生类的实例(对应于GoF设计模式系列里的“工厂模式”)

解决方案:如果符合下面的一个或多个条件,则将创建类A实例的职责分配给类B.

.类B聚合类A的对象。
.类B包含类A的对象。
.类B记录类A对象的实例。
.类B密切使用类A的对象。
.类B初始化数据并在创建类A的实例时传递给类A(类B是创建类A实例的一个专家)。

在以上情况下,类B是类A对象的创建者。 控制器模式 问题:谁处理一个系统事件?

解决方案:当类代表下列一种情况时,为它分配处理系统事件消息的职责。
.代表整个系统、设备或子系统(外观控制器)。
.代表系统事件发生的用例场景(用例或回话控制器)。 低耦合 问题:如何支持低依赖性以及增加重用性?

解决方案:分配职责时使(不必要的)耦合保持为最低。 高内聚 问题:如何让复杂性可管理?

解决方案:分配职责时使内聚保持为最高。 多态模式 问题:当行为随类型变化而变化时谁来负责处理这些变化?

解决方案:当类型变化导致另一个行为或导致行为变化时,应用多态操作将行为的职责分配到引起行为变化的类型。 纯虚构模式 问题:当不想破坏高内聚和低耦合的设计原则时,谁来负责处理这些变化?

解决方案:将一组高内聚的职责分配给一个虚构的或处理方便的“行为”类,它并不是问题域中的概念,而是虚构的事务,以达到支持高内聚、低耦合和重用的目的。 中介模式 问题:如何分配职责以避免直接耦合?

解决方案:分配职责给中间对象以协调组件或服务之间的操作,使得它们不直接耦合。 受保护变化模式 问题:如何分配职责给对象、子系统和系统,使得这些元素中的变化或不稳定的点不会对其他元素产生不利影响?

解决方案:找出预计有变化或不稳定的元素,为其创建稳定的“接口”而分配职责。

本文地址:http://com.8s8s.com/it/it33058.htm