解决方案：分配一个职责，是的保持低耦合度。问题：怎样支持低的依赖性，减少变更带来的影响，提高重用性？耦合（coupling）是测量一个元素连接、了解或者依赖其它元素强弱的尺度。具有低耦合的的元素不过多的依赖其它的元素，“过多”这个词和元素所处的语境有关，需要进行考查。元素包括类、子系统、系统等。具有高耦合性地类过多的依赖其它的类，设计这种高耦合的类是不受欢迎的。因为它可能出现以下问题：a 相关类的变化强制局部变化。b当元素分离出来的时候很难理解 c 因为使用高耦合类的时候需要它所依赖的类，所以很难重用。示例：我们来看一下POS 机的例子，有如下三个类。Payment（付款）、Register（登记）、Sale（销售）。 要求：创建一个Payment类的实例，并且与 Sale相关联。哪个类更适合完成这项工作呢？创建者模式认为，Register记录了现实世界中的一次Payment，因此建议用Register作为创建者。第一方案：由 Register构造一个Payment对象。 再由Register把构造的Payment实例通过 addPayment 消息发送给 Sale对象。

    第二方案：

    由 Register向 Sale提供付款信息（通过 makePayment消息），再由Sale创建Payment对象。

    两种方案到底那种支持低的耦合度呢？第一方案，Register构造一个Payment对象，增加了Register与Payment对象的耦合度。第二方案，Payment 对象是由 Sale 创建的，因此并没有增加 Register 与 Payment 对象的耦合度。单纯从耦合度来考虑，第二种方案更优。在实际工作中，耦合度往往和其它模式是矛盾的。但耦合性是提高设计质量必须考虑的一个因素。 耦合分类：1，无任何连接：两个模块中的每一个都能独立地工作而不需要另一个的存在（最低耦合）。2，数据耦合：两个模块彼此通过参数交换信息，且交换的仅仅是数据（低耦合）。 3，控制耦合：两个模块之间传递的信息有控制成分（中耦合）。4，公共环境耦合：两个或多个模块通过一个公共环境相互作用：a 一个存数据，一个取数据（低耦合）；b 都存取数据（低--中之间）。5，内容耦合（一般比较高）：a 一个模块访问另一个模块的内部数据；b个模块有一部分程序代码重叠；c一个模块不通过正常入口而转移到另一个的内部；d一个模块有多个入口（意味着该模块有多个功能）。讨论：在确定设计方案的过程中，低耦合是一个应该时刻铭记于心的原则。它是一个应该时常考虑的设计目标，在设计者评估设计方案的时候，低耦合也是一个评估原则。低耦合使类的设计更独立，减少类的变更带来的不良影响，但是，我们会时时发现低耦合的要求，是和其它面向对象的设计要求是矛盾的，这就不能把它看成唯一的原则，而是众多原则中的一个重要的原则。比如继承性必然导致高的耦合性，但不用继承性，这就失去了面向对象设计最重要的特点。没有绝对的尺度来衡量耦合度，关键是开发者能够估计出来，当前的耦合度会不会导致问题。事实上越是表面上简单而且一般化的类，往往具有强的可重用性和低的耦合度。低耦合度的需要，导致了一个著名的设计原则，那就是优先使用组合而不是继承。但这样又会导致许多臃肿、复杂而且设计低劣的类的产生。所以，一个优秀的设计师，关键是用一种深入理解和权衡利弊的态度来面对设计。设计师的灵魂不是记住了多少原则，而是能灵活合理的使用这些原则，这就需要在大量的设计实践中总结经验，特别是在失败中总结教训，来形成自己的设计理念。