面向对象原则——2012.ppt

面向对象设计原则 阚忠良 kanzl@ OOAD的基本原则 学习了ＵＭＬ的规范表示法并不能保证会很好地使用这些表示法，好的设计和不好的设计都可以用UML表达。 面向对象设计师们积累了一些被广泛认可的高级设计原则。这些设计原则描述了应当具有的或者应当避开的值得注意的性质。 与结构化设计相比，我们注意到面向对象的设计理念具有天生的敏捷性。无论是封装、继承还是多态特征，其根本目的是在未来发生变化的时候，不至于对产品结构产生崩溃性的影响。但是，并不等于我们使用了面向对象的语言就自然具备了面向对象设计的优点，还需要更多的设计原则来保证我们在需求发生变化的情况下系统结构的合理性。 面向对象设计是在迭代开发过程中完成的，架构的设计应该适应变更。我们的设计理念将更加强调拥抱变化而设计。根据这样一个基本原则，延伸出了诸如单一职责原则、开闭原则、依赖倒置原则、接口隔离原则、包的内聚性原则以及包的依赖性原则等一系列设计原则。这些原则极大丰富了软件设计理念，扩展了软件设计方法论 OOAD的基本原则 单一职责原则 开闭原则 优先使用组合而非继承 针对接口编程，而非实现 Liskov代换原则 依赖倒置原则 接口分离原则 单一职责原则 Single Responsibility Principle （SRP） 这条原则也被称之为内聚性原则。内聚性的原始定义为一个模块的组成元素之间的功能的相关性。但是在我们的问题中，我们稍微改变一下它的含义，由于我们关注的是需求变更造成的影响，所以我们把内聚性和引起一个模块或者类改变的作用力联系起来。SRP原则的描述为：就一个类而言，应该仅有一个引起它变化的原因 单一职责原则 职责是变化的一个轴线 （1）普通的设计方法是以功能相关为依据进行封装即以功能内聚为设计原则的。 考虑图中的设计。Triangle类具有具有两个方法，一个方法是把三角形绘制在屏幕上，另一个方法是计算三角形的面积。从功能内聚的观点来看，这没有什么问题。 当两个不同的应用程序（ComputationalGeometryApplication和GraphicalApplication）使用Triangle类，一个是有关计算几何学方面的，Triangle会在几何形状计算方面为它提供帮助，它不会在屏幕上绘制三角。另一个应用程序实质上是有关图形绘制方面的，它可能也会进行一些计算几何学方面的工作，但是它肯定会在屏幕上绘制三角形。 （2）单一职责原则主要考虑变化的原因 这个设计违反了单一职责原则，Triangle类具有两个职责，第一个职责提供了三角形几何形状的数学模型；第二个职责是把三角形在一个图形用户界面上绘制出来。而这两个职责变化的轴线是不一样的。 对于SRP原则的违反将导致一些问题。首先，我们必须在计算几何应用程序中包含GUI代码。如果这是一个C++应用程序，就必须把GUI代码连接进来，这会浪费链接时间、编译时间以及内存占用，如果是一个Java应用程序，GUI的class文件就必须要被部署到目标平台。其次，如果GraphicalApplication的改变由于这些原因导致Triangle的改变，那么这个改变会迫使我们重新构建、测试和部署ComputationalGeometryApplication。如果忘掉了这样做，ComputationalGeometryApplication将会以不可预测的方式失败。 （3）比较好的设计是分离不同的变化职责 一个较好的设计是把两个职责分离到两个完全不同的类中，如图所示。我们把Triangle类中进行计算的部分移到GeometryTriangle类中。现在绘制方式的改变不会对ComputationalGeometryApplication造成影响。 这种分离的原因是由于每个职责都是变化的一个轴线。当需求变化时，该变化会反映为类的职责的变化。如果一个类承担了多于一个的职责，那么引起它变化 的原因就会有多个。如果一个类承担的职责过多，就等于把这些职责耦合在了一起。一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当变化发生时，设计会遭受到意想不到的破坏。 分离耦合的职责 （1）在SRP中的职责定义为“变化的原因” 在SRP中，我们把职责定义为“变化的原因”。如果能够想到多于一个的动机去改变一个类，那么这个类就具有多于一个的职责。有时，我们很难注意到这一点。我们习惯于以组的形式考虑职责。例如：考虑下面的Modem接口。大多数人会认为这个接口看起来非常合理。该接口所声明的四个函数确实是调制解调器所具有的功能。 interface Modem{ public void dial(String pno); public void hangup(); public v