职责分配模式分析准备

问题：
在面向对象的系统中是由多个对象组成的，这些对象必需能够向其它对象发送消息或操作，这就是对象的交互和职责分配。不过由于对象的交互和职责的分配没有固定的标准，所以它的设计质量就有很大的可变性，差的系统设计会导致系统和构件脆弱和难以维护，重用和扩展。为了使你的系统设计的完美，必需有一个设计原则用于建立交互图和职责的分配，这就是GRASP（General Responsibility Assignment Software Pattern）
什么是职责
职责：简单的说就是各个对象要完成的功能，也许有人会说有一些像对象的方法，也对。不过也有不同，比如“访问数据库”的职责就不是一个方法可以完成的，必需要多个类和方法配合才可以的，而一些简单的职责用一个方法就可以完成了，比如“计算1+1”。由此可见职责和方法还是些不同的，职责是通过方法来实现的。实现职责可以通过一个单独的起作用的方法来完成，但是如果职责复杂的话必需由多个方法和对象配合完成。
怎样分配职责
怎样分配职责是个很模糊的话题，每个人都有自己的经验，不过还是有一定的规则可寻的。如果用的好的话不仅可以避免风险，而且可能增强软件的质量。在这些规律中有五种最基本的方法，即大家说的五种模式：
1 专家模式（Expert）
2 创建者模式（Creator）
3 高聚合度或高内聚（high Cohesion）
4 低耦合度或低耦合 （Low Coupling）
5 控制者模式 （Controller）
此外还有其它一些模式，不过这五种是基础。要熟练的对对像的职责进分配就必须撑握。
下面是对五种模式的分析：
专家模式：它的实质就是在满足这个职责所有的必需知道的信息的类上分配该职责。也许大家对这样的说法还不是很清楚的，下面的一个例子则是对它的说明。我们在购买商品时需要计算商品的总价格，计算商品的总价格就是一个职责，如果你有面向对象分析的基础，就可分析出这里有两个对象(这里的分析有一些问题J,只是为了说明问题)，Sale 和 Product , 计算商品的总价格则是一个职责total,它必需的信息有Product 的价格和Product 的数量,Product中只有价格没有数量,而Sale中输入数量和商品的信息,通过商品的信息你可以间接得到商品的价格,所以根据专家模式把total放在Sale中（也不知道你们是否明白，反正我是清楚了J）。
创建者模式：主要解决的是类实例的创建和指导对象实例创建任务的分配，即由谁负责创建一个类的实例。当你发现以下条件满足时就可以用B对象创建成A对象：
1B聚集了A对象
2B包含了A对象
3B记录了A对象了实例
4B要经常使用A对象
比如上面说的Sale中可能会有多个Product,则由Sale来创建Product比较好。
高聚合和低耦合是大家都熟悉的，也就是说对象之间必须保持独立，不要依赖于其它对象，同时各职责必须有高度的内聚，不过这两种原则在使用时必须和其它原则相配合，不可以孤立的考虑。
最后要说的是控制者模式，简单的说是谁来负责系统事件。初次接触UML的人也许不是很了解的，首先要先了解系统事件，系统事件可以想象成由系统外部参预者发起的高层事件，一个比较好的方法是利用系统顺序图来（Sequence）来寻找它，它的发起者是系统的使用者即角色。例如一个销售处的售货员按下endsale,则endsale是一个系统事件。控制者模式就是将系统事件消息的职责分派给代表下面事物的类，经常用的有以下几种：
1代表整个系统的类
2代表某个部分功能的类
3代表某个角色的类（角色控制者类），系统的参预者
不过这里要注意系统的接口对象不处理系统事件，其实这样的要求也符合三层开发原则（Brower层和业务逻辑层的分离），换句话说，系统操作反映的是业务逻辑应该由业务逻辑层来处理，而不是由系统的接口层来负责。
这五种模式是一般的职责分配方式，我认为是基础的基础，你可以通过它灵活的使用来建立系统的交互图，实现系统的设计。