面向对象分析设计原则

一、单一职责原则(SRP)

就一个类而言,应该仅有一个引起它变化的原因。软件设计真正要做的许多内容,就是发现职责并把那些职责相互分离。测试驱动的开发实践常常会在设计出现臭味之前就迫使我们分离职责。

二、开闭原则(OCP)

软件实体(类、模块、函数)应该是可扩展的,但是不可修改的。也就是说:对于扩展是开放的,对于更改是封闭的。怎样可能在不改动模块源代码的情况下去更改它 的行为呢?怎样才能在无需对模块进行改动的情况下就改变它的功能呢?关键是抽象!因此在进行面向对象设计时要尽量考虑接口封装机制、抽象机制和多态技术。 该原则同样适合于非面向对象设计的方法,是软件工程设计方法的重要原则之一。

三、替换原则(LSP)

子类应当可以替换父类并出现在父类能够出现的任何地方。这个原则是Liskov于1987年提出的设计原则。它同样可以从Bertrand Meyer 的DBC (Design by Contract〔基于契约设计〕) 的概念推出。

四、依赖倒置原则(DIP)

1、 高层模块不应该依赖于低层模块。二者都应该依赖于抽象。2、抽象不应该依赖于细节。细节应该依赖于抽象。在进行业务设计时,与特定业务有关的依赖关系应该 尽量依赖接口和抽象类,而不是依赖于具体类。具体类只负责相关业务的实现,修改具体类不影响与特定业务有关的依赖关系。在结构化设计中,我们可以看到底层 的模块是对高层抽象模块的实现(高层抽象模块通过调用底层模块),这说明,抽象的模块要依赖具体实现相关的模块,底层模块的具体实现发生变动时将会严重影 响高层抽象的模块,显然这是结构化方法的一个"硬伤"。面向对象方法的依赖关系刚好相反,具体实现类依赖于抽象类和接口。

五、接口分离原则(ISP)

采用多个与特定客户类有关的接口比采用一个通用的涵盖多个业务方法的接口要好。 ISP原则是另外一个支持诸如COM等组件化的使能技术。缺少ISP,组件、类的可用性和移植性将大打折扣。这个原则的本质相当简单。如果你拥有一个针对多个客户的类,为每一个客户创建特定业务接口,然后使该客户类继承多个特定业务接口将比直接加载客户所需所有方法有效。

以 上五个原则是面向对象中常常用到的原则。此外,除上述五原则外,还有一些常用的经验诸如类结构层次以三到四层为宜、类的职责明确化(一个类对应一个具体职 责)等可供我们在进行面向对象设计参考。但就上面的几个原则看来,我们看到这些类在几何分布上呈现树型拓扑的关系,这是一种良好、开放式的线性关系、具有 较低的设计复杂度。一般说来,在软件设计中我们应当尽量避免出现带有闭包、循环的设计关系,它们反映的是较大的耦合度和设计复杂化。

面向对象之代码复用规则

1、 对接口编程

"对接口编程"是面向对象设计(OOD)的第一个基本原则。它的含义是:使用接口和同类型的组件通讯,即,对于所有完成相同功能的组件,应该抽象出一个接口,它们都实现该接口。具体到JAVA中,可以是接口,或者是抽象类,所有完成相同功能的组件都实现该接口,或者从该抽象类继承。尽量使用接口。接口只是对象打交道的入口,只有具有继承关系才使用抽象类。

2、 优先使用对象组合,而不是类继承

"优先使用对象组合,而不是类继承"是面向对象设计的第二个原则。并不是说继承不重要,而是因为每个学习OOP的人都知道OO的基本特性之一就是继承,以至于继承已经被滥用了,而对象组合技术往往被忽视了。只有有现实生活中的父子关系才使用继承。

相关的设计模式有:Bridge、Composite、Decorator、Observer、Strategy等。

3、 将可变的部分和不可变的部分分离

"将可变的部分和不可变的部分分离"是面向对象设计的第三个原则。如果使用继承的复用技术,我们

你可能喜欢

  • 面向对象分析与设计
  • 面向对象设计
  • 面向对象的设计原则
  • 软件设计模式
  • 考试试题及答案
  • 面向对象软件工程
  • 面向对象方法
  • 系统工程

面向对象分析设计原则的相关文档搜索

面向对象分析设计原则相关文档

最新文档

返回顶部