面向对象分析设计原则.docVIP

一、单一职责原则（ＳＲＰ） ?????? 就一个类而言，应该仅有一个引起它变化的原因。软件设计真正要做的许多内容，就是发现职责并把那些职责相互分离。测试驱动的开发实践常常会在设计出现臭味之前就迫使我们分离职责。 ?????? 二、开闭原则（ＯＣＰ） ?????? 软件实体（类、模块、函数）应该是可扩展的，但是不可修改的。也就是说：对于扩展是开放的，对于更改是封闭的。怎样可能在不改动模块源代码的情况下去更改它 的行为呢？怎样才能在无需对模块进行改动的情况下就改变它的功能呢？关键是抽象！因此在进行面向对象设计时要尽量考虑接口封装机制、抽象机制和多态技术。 该原则同样适合于非面向对象设计的方法，是软件工程设计方法的重要原则之一。 ?????? 三、替换原则（ＬＳＰ） ?????? 子类应当可以替换父类并出现在父类能够出现的任何地方。这个原则是Liskov于1987年提出的设计原则。它同样可以从Bertrand Meyer 的DBC (Design by Contract〔基于契约设计〕) 的概念推出。 ?????? 四、依赖倒置原则（ＤＩＰ） １、 高层模块不应该依赖于低层模块。二者都应该依赖于抽象。２、抽象不应该依赖于细节。细节应该依赖于抽象。在进行业务设计时，与特定业务有关的依赖关系应该 尽量依赖接口和抽象类，而不是依赖于具体类。具体类只负责相关业务的实现，修改具体类不影响与特定业务有关的依赖关系。在结构化设计中，我们可以看到底层 的模块是对高层抽象模块的实现（高层抽象模块通过调用底层模块），这说明，抽象的模块要依赖具体实现相关的模块，底层模块的具体实现发生变动时将会严重影 响高层抽象的模块，显然这是结构化方法的一个硬伤。面向对象方法的依赖关系刚好相反，具体实现类依赖于抽象类和接口。 五、接口分离原则（ＩＳＰ） 采用多个与特定客户类有关的接口比采用一个通用的涵盖多个业务方法的接口要好。　　ISP原则是另外一个支持诸如COM等组件化的使能技术。缺少ISP，组件、类的可用性和移植性将大打折扣。这个原则的本质相当简单。如果你拥有一个针对多个客户的类，为每一个客户创建特定业务接口，然后使该客户类继承多个特定业务接口将比直接加载客户所需所有方法有效。 以 上五个原则是面向对象中常常用到的原则。此外，除上述五原则外，还有一些常用的经验诸如类结构层次以三到四层为宜、类的职责明确化（一个类对应一个具体职 责）等可供我们在进行面向对象设计参考。但就上面的几个原则看来，我们看到这些类在几何分布上呈现树型拓扑的关系，这是一种良好、开放式的线性关系、具有 较低的设计复杂度。一般说来，在软件设计中我们应当尽量避免出现带有闭包、循环的设计关系，它们反映的是较大的耦合度和设计复杂化。 面向对象之代码复用规则 　　对接口编程是面向对象设计（OOD）的第一个基本原则。它的含义是：使用接口和同类型的组件通讯，即，对于所有完成相同功能的组件，应该抽象出一个接口，它们都实现该接口。具体到JAVA中，可以是接口，或者是抽象类，所有完成相同功能的组件都实现该接口，或者从该抽象类继承。尽量使用接口。接口只是对象打交道的入口，只有具有继承关系才使用抽象类。 2、 优先使用对象组合，而不是类继承 　　优先使用对象组合，而不是类继承是面向对象设计的第二个原则。并不是说继承不重要，而是因为每个学习OOP的人都知道OO的基本特性之一就是继承，以至于继承已经被滥用了，而对象组合技术往往被忽视了。只有有现实生活中的父子关系才使用继承。 　　相关的设计模式有：Bridge、Composite、Decorator、Observer、Strategy等。　 3、 将可变的部分和不可变的部分分离 　　将可变的部分和不可变的部分分离是面向对象设计的第三个原则。如果使用继承的复用技术，我们可以在抽象基类中定义好不可变的部分，而由其子类去具体实现可变的部分，不可变的部分不需要重复定义，而且便于维护。如果使用对象组合的复用技术，我们可以定义好不可变的部分，而可变的部分可以由不同的组件实现，根据需要，在运行时动态配置。这样，我们就有更多的时间关注可变的部分。 　　对于对象组合技术而言，每个组件只完成相对较小的功能，相互之间耦合比较松散，复用率较高，通过组合，就能获得新的功能。 4、 减少方法的长度 　　通常，我们的方法应该只有尽量少的几行，太长的方法会难以理解，而且，如果方法太长，则应该重新设计。对此，可以总结为以下原则： 三十秒原则： 　　如果另一个程序员无法在三十秒之内了解你的函数做了什么（What），如何做(How)以及为什么要这样做(Why)，那就说明你的代码是难以维护的，必须得到提高； 一屏原则：如果一个函数的代码长度超过一个屏幕，那么或许这个函数太长了，应该拆分成更小的子函数；