|
|
|
面向对象设计是把分析阶段得到的需求转变成符合成本和质量要求的、抽象的系统实现方案的过程。从面向对象分析到面向对象设计，是一个逐渐扩充模型的过程。瀑布模型把设计进一步划分成概要设计和详细设计两个阶段，类似地，也可以把面向对象设计再细分为系统设计和对象设计。系统设计确定实现系统的策略和目标系统的高层结构。对象设计确定解空间中的类、关联、接口形式以及实现操作的算法。
|
|
|
|
面向对象设计的一些基本准则是：模块化、抽象、信息隐藏、高内聚和低耦合。下面，我们将具体介绍一些面向对象设计（含设计模式）的原则，这些原则有助于开发人员设计出具有弹性的系统，从而消除系统设计中存在的问题。
|
|
|
|
（1）单一职责原则。这是模块内聚性在类和类的职责中的体现，如果一个类承担的职责过多，意味着这些职责耦合在一起，形成的很有可能是一个“杂凑类”，任一个职责的变化可能会削弱或者抑制该类完成其他职责的能力，并影响到构建、测试和部署等活动。通过业务分离可以对概念进行解耦，从而得到目的单一的类。
|
|
|
|
（2）开放－封闭原则。在模块本身不变动的情况下，通过改变模块周围的环境达到修改目的。遵循开放－封闭原则设计出的模块具有一个主要特征，即对于扩展是开放的，对于修改是封闭的。也就是说，模块的行为是可扩展的，当应用的需求改变时，在模块上进行扩展使其具有满足那些改变的新行为。当模块进行扩展时，不必改动模块的源代码或二进制代码。
|
|
|
|
（3）李氏（Liskov）替换原则。子类型必须能够替换掉它们的基类型；子类具有扩展父类的责任，而不是重写的责任。也就是说，基类的使用者不必为了使用子类而做任何其他的事情，他们可以在根本不了解子类的特殊性，甚至不必知道是否存在子类，存在哪些子类的情况下来调用基类的抽象方法。这样多态性才能顺利实现。事实上，正是Livkov替换原则，才使开放－封闭原则得以实现，因为正是子类的可替换性才使得基类的模块在无需修改的情况下就可以扩展。
|
|
|
|
（4）依赖倒置原则。高层模块不应该依赖于低层模块，二者都应该依赖于抽象；抽象不应该依赖于细节，但细节应该依赖于抽象。每个较高的层次都为它需要的服务声明一个抽象接口，较低的层次实现这个接口，每个高层类都通过该抽象接口使用下一层，要依赖于抽象，而不是具体实现。也可以这样说，要针对接口编程，不要针对实现编程。
|
|
|
|
（5）接口隔离原则。应当为客户端提供尽量小的单独的接口，而不是提供大的接口；使用多个专门的接口比使用单一的总接口要好。也就是说，一个类对另外一个类的依赖性应当是建立在最小的接口上的。这里的“接口”往往有两种不同的含义：一种是指一个类型所具有的方法特征的集合，仅仅是一种逻辑上的抽象；另外一种是指某种语言具体的“接口”定义，有严格的定义和结构。在进行OOD的时候，一个重要的工作就是恰当的划分角色和角色对应的接口。将没有关系的接口合并在一起，是对角色和接口的“污染”。如果将一些看上去差不多的接口合并，并认为这是一种代码优化，这也是错误的。不同的角色应该交给不同的接口，而不能都交给一个接口。
|
|
|
|
（6）组合重用原则：要尽量使用组合，而不是继承关系达到重用目的。组合相比于继承的好处：更大的灵活性而不会影响调用代码；更短的编译时间；适用性更广；较好的健壮性和安全性，更少的复杂性和脆弱性，更好的可维护性；能够在运行期创建新的对象。当然，耦合度的降低又会增加设计的难度、系统的复杂性以及实现的成本等，因此，在设计过程中，必须对这些因素综合考虑。
|
|
|
|
（7）迪米特（Demeter）原则。又叫最少知识法则（Least Knowledge Principle, LKP），就是说一个对象应当对其他对象有尽可能少的了解。遵循类之间的迪米特原则会使一个系统的局部设计简化，因为每一个局部都不会和远距离的对象有直接的关联。但是，这也会造成系统的不同模块之间的通信效率降低，也会使系统的不同模块之间不容易协调。迪米特原则在类的设计上主要体现在：优先考虑将类设置成不变类，尽量降低类的访问权限，谨慎使用Serializable，尽量降低成员的访问权限。但遵循该原则，会在系统中造出大量的小方法，这些方法仅仅是传递间接的调用，与系统的商务逻辑无关。
|
|
|
