软件工程（1）
GRASP 设计模式
1. 创建者(Creator)
问题：谁应该负责创建一个类的新实例？
解决方案：如果满足以下条件之一，则将创建类A实例的职责交给类B（B创建A）。
B包含或组成聚集A
B直接使用A
B具有A的初始化数据，并在创建A时，将这些数据传给A
如果有多个类B满足以上条件，一般首选，包含或组成聚集类A的B。
支持低耦合， 因为A本身对于其创建者B就是可见的（即本身就有关联）所以不会增加耦合性
相关模式：
具体工厂和抽象工厂
问题：给对象分配职责的基本原则是什么？
解决方案：将职责分配给信息专家（如果一个类拥有完成某个职责的所有信息，那么他就是这个职责的信息专家）。完成一个职责往往需要不同类中的信息，所以这些局部的信息专家可能需要协作来完成一个职责。
对象的职责：
行为职责：
自身执行一些行为，如创建对象和计算。
初始化其他对象中的动作。
控制和协调其他对象中的活动。
认知职责：
对私有封装数据的认知。
对相关对象的认知。
对其能够导出或计算出事物的认知。
支持低耦合，因为对象使用自身信息完成任务，所以支持了低耦合
相关模式：
3. 低耦合(Low Coupling)
耦合的定义： 耦合是对某元素与其他元素之间的连接，感知和依赖程度的度量。低耦合意味着类不会过度依赖其他类。
问题： 怎样降低依赖性，减少变化带来的影响，提高重用性？
解决方案： 分配职责。
下面这些情况会造成类A、B之间的耦合：
A是B的属性
A调用B的实例的方法
A的方法中引用了B，例如B是A方法的返回值或参数。
A是B的子类，或者A实现了B
不受其他构件变化的影响。
易于单独理解。
便于复用。
相关模式：
4. 控制器(Controller)
问题：在UI层之上首先接收和协调系统操作的第一个对象是什么？
解决方案：把职责分配给以下类
代表整个系统，根对象，运行软件的设备或主要系统。
代表用例场景，在该场景中发生系统事件。
控制器是UI层之上的第一个对象，他负责接收和处理系统操作信息。
准则：正常情况下，控制器应该把需要完成的工作委派给其他的对象。控制器只是协调或控制这些活动，本身并不完成大量工作。
提供了可复用和接口可插拔的潜力。
相关模式：
5. 高内聚(High Cohesion)
内聚的定义：内聚是对元素职责相关性和集中度的度量。如果元素具有高度相关的职责，而且没有过多的工作，那么该元素具有高内聚性。
问题：怎样保证对象是有重点的，可理解的，可管理的，并且能够支持低耦合。
解决方案：分配职责，内聚性较低的类要完成许多不相关的职责，需要完成大量的工作，所以是不合理的。
简化了维护和改进的工作
通常支持低耦合
相关功能重用性增强
相关模式：
6. 多态性(Polymorphism)
问题：如何处理基于类型的选择？如何创建可插拔的软件构件？
基于类型的选择：如果使用 if-else 来处理系统的变化，那么当出现变化时，需要修改这些遍布程序各处的case。
可插拔软件构件：如何替换服务器中的构件而不对客户端形成影响。
易于新变化所需要的扩展
无需影响客户便能够引入新的实现
相关模式：
7. 纯虚构(Pure Fabrication)
问题：当你并不想违背高内聚和低耦合或其他目标，但是基于专家模式所提供的方案又不适合时，哪些对象承担这一职责？
解决方案：创建一个凭空虚构的类，并为它分配职责。
支持高内聚
增加可复用性
相关模式：
8. 间接性(Indirection)
问题：为了避免两个或多个事物之间直接耦合，应该如何分配职责？
解决方案：将职责分配给中介对象，使其作为媒介。
支持了低耦合
相关模式：
9. 防止变异(Protected Variations)
问题：如何设计对象，子系统和系统，使其内部的变化和不稳定性不会对其他元素产生不良影响。
解决方案：识别预计变化或不稳定之处，并在这些变化之外创建接口。
不要说话准则：在方法中，只应该给以下对象发送消息
this对象（自身）
方法的参数
this的属性
作为this属性的集合中的元素
在方法中创建的对象
两种变化方法：
变化点：现有、当前系统或需求中的变化
进化点：预测将来可能会产生的变化点，但并不存在于现有需求中
易于增加新变化所需的扩展
可以引入新的实现而不影响用户
能够减少变化带来的成本或影响
参考书目： UML和模式应用
&&相关文章推荐
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：1927次
排名：千里之外
原创：17篇
(2)(1)(9)(8)
(window.slotbydup = window.slotbydup || []).push({
id: '4740887',
container: s,
size: '250,250',
display: 'inlay-fix'当前位置：
/ 如何在标题名中快速区分bug,需求,与任务？
如题，因为目前公司的发版是根据禅道的任务号来合并的，因为产品经理觉得复杂，所以目前要将一部分任务分流到bug与需求上。但由于程序员在提交代码时是直接复制标题的。所以有没有一个快捷的方法快速区分当前bug/任务是哪一个种类的？
8.1.3 Windows一键***包操作系统
Windows Server 2008客户端浏览器
提问者： 张从心 悬赏：5 日期：
10:37:58 ***：1 点击 269
看当前所在的页面是bug还是需求还是任务，要在标题上列出类型的话需要修改代码实现。