面向对象与编程原则--11 .ppt

设计模式(1) 导言:面向对象设计原则 目录 1 面向对象的设计原则 2 设计模式概论 3 单件 4 观察者 面向对象的设计原则 1单一职责SRP 2.OCP开闭原则 3.里氏代换LSP 4.依赖倒转DIP 5.接口隔离ISP 6.迪米特法则LOD 7合成聚合复用原则（CARP） Booch和Rumbaugh的新的“统一”标识符 单一职责SRP 一个优良的系统设计，强调模块间保持低耦合、高内聚的关系，在面向对象设计中这条规则同样适用，所以面向对象的第一个设计原则就是：单一职责原则（SRP，Single Responsibility Principle）。 单一职责，强调的是职责的分离，在某种程度上对职责的理解，构成了不同类之间耦合关系的设计关键，因此单一职责原则或多或少成为设计过程中一个必须考虑的基础性原则。 1.单一职责原则（SRP） 一个类，最好只做一件事，只有一个引起它变化的原因。 例如，在一个Game类中，可能会具有两个不同的职责，一个职责是维护创建当前轮的比赛，另一个职责是计算总比赛得分。根据srp原则，着两个职责应该分离到两个类中，Game类保持维护创建当前轮的比赛，Scorer类负责计算比赛的得分。 如何要把这两个职责分离到单独的类中呢？ 如果一个类承担的职责过多，等于把这些职责耦合在了一起。一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当变化发生时，设计会遭受到意想不到的破坏。 例如，考虑下图的设计。Retangle类具有两方法，如图。一个方法把矩形绘制在屏幕上，另一个方法计算矩形的面积。 有两个不同的Application使用Rectangle类，如上图。一个是计算几何面积的，Rectangle类会在几何形状计算方面给予它帮助。另一个Application实质上是绘制一个在舞台上显示的矩形。 Rectangle类具有了两个职责，第一个职责是提供一个矩形形状几何数据模型；第二个职责是把矩形显示在屏幕上。 对于SRP的违反导致了一些严重的问题。首先，我们必须在计算几何应用程序中包含核心显示对象的模块。其次，如果绘制矩形Application发生改变，也可能导致计算矩形面积Application发生改变，导致不必要的重新编译，和不可预测的失败。 一个较好的设计是把这两个职责分离到下图所示的两个完全不同的类中。这个设计把Rectangle类中进行计算的部分一道GeometryRectangle类中。 现在矩形绘制方式的改变不会对计算矩形面积的应用产生影响了。 1.1 什么是职责 在SRP中，我们把职责定义为“变化的原因”(a reason for change)。如果你能够想到多于一个的动机去改变类，那么这个类就具有多于一个的职责。有时，我们很难注意到这一点。我们习惯于以组的形式去考虑职责。 class Modem{ public : void dial(pno:String): ; void hangup(): ; void send(c:Char): ; void recv(): ; } 上述Modem接口，大多数人会认为这个接口看起来非常合理。该接口声明了4个函数确实是Modem所具有的功能。然而，该接口却显示出了两个职责，一个是连接管理（dial+hangup），第二个是数据通信（send+recv）。 这两个职责应该被分离开么？这依赖于应用程序的变化。 是按照实际情况决定的。如果应用程序的变化会影响连接管理，那么设计就具有僵化的臭味。因为，调用send和recv的类必须要重新编辑。在这种情况下，这两个职责应该被分离，这样做会避免这两个职责耦合在一起。 另一方面，如果应用程序的变化总是导致这两方面职责同时变化，那么就不必分离他们。实际上，分离他们就会具有不必要的复杂性臭味 1.2 持久化 上图展示了一种常见的违反SRP的情况，Employee类包含了业务逻辑和对于持久层的控制。这两个职责在大多数情况下决不应该混合在一起。 业务规则往往会频繁的变化，而持久化的方式却不会如此频繁的变化，并且变化的原因也是完全不同的。把业务规则和持久模块绑定在一起的做法是不妥的。当僵化性和脆弱性的臭味变得强烈，那么就应该使用FACADE和PROXY模式对设计进行重构，分离这两个职责。 小结： SRP是所有原则中最简单的之一，也是最难正确应用的。我们会自然的把职责结合在一起。软件设计要做的许多内容，就是发现职责并把那些职责相互分