面向对象设计的11原则
2010-07-03 21:44
309 查看
面向对象设计是什么？都包含了哪些内容？它所带来的好处是什么？需要你为之付出些什么？在如今这个年代，问这些问题似乎显得很愚蠢，因为这年头几乎每位软件开发人员都知道如何使用某种面向对象编程语言。可是这个问题还是很重要，因为在我看来，绝大多数人在使用这些语言的时候并不知道为什么，而且也不知该如何最充分的运用它们。
软件业曾经爆发过的所有变革里，其中曾经有两个派系如此广泛的深入人心，它们就是结构化编程和面向对象编程。所有主流的现代编程语言都被它们两个激烈的影响着。实际上，要想不像结构化和面向对象编程的样子来编写程序都是一件难事。我们的主流编程语言都没有goto，因此它们服从了结构化编程中最重要的禁令。我们的大多数主流编程语言都是基于类的，而且不支持在类以外定义函数或是变量，因此也避免了面向对象编程中最容易坠入的陷阱。
用这些编程语言所编写的程序可能看起来是结构化的或是面向对象的，可是“看起来”是会欺骗人的。当今的编程语言经常不顾他们所从属那种派系的编程语言的基本原则。我会在另篇blog中再探讨结构化编程的原则，本篇，我想要谈论的是面向对象编程的基本原则。
在1995年的三月，我写了一篇文章并发表在comp.object上，那是我第一次写OOD（译注1）原则的文章，此后就一发不可收拾的写了很多。你可以在我的PPP一书（译注2）中看到它们，在object mentor的很多文章中也都有，其中就有那篇众所周知的纲要（近期会译为中文，请关注）。
这些原则着重于OOD中的依赖管理方面，而淡化抽象与建模方面。这并不是说OO在抽象方面不够强大，或是OO不适合构建模型。当然有很多人都在使用OO的这些部分，只是这些原则集中关注于依赖管理。
依赖管理是我们每个人都要面对的问题，每当我们在屏幕面前打开那些彼此纠结又令人作呕的代码，我们就会遭受不良的依赖管理所带来的恶果。不良的依赖管理导致代码难以改变，易被破坏，而且不可重用。实际上，我在PPP一书中谈论过很多不同的设计坏味道，而这些都与依赖管理有关。从另一方面来说，如果依赖经过了良性的管理，代码就可以保持灵活性、健壮性和重用性。所以依赖管理和这些相关原则是程序员们渴求的让软件保持优良架构的基石。
头七项原则是关于类设计的，它们是：
SRP，单一职责原则，一个类应该有且只有一个改变的理由。
OCP，开放封闭原则，你应该能够不用修改原有类就能扩展一个类的行为。
LSP，Liskov替换原则，派生类要与其基类自相容。
DIP，依赖倒置原则，依赖于抽象而不是实现。
ISP，接口隔离原则，客户只要关注它们所需的接口。
CARP，合成/聚合复用原则，要尽量使用组合、聚合，而不是继承关系以达到复用的目的
LoD，迪米特法则，一个软件实体应该与尽可能少的其他实体发生互相作用
一、单一职责原则（ＳＲＰ）
就一个类而言，应该仅有一个引起它变化的原因。软件设计真正要做的许多内容，就是发现职责并把那些职责相互分离。测试驱动的开发实践常常会在设计出现臭味之前就迫使我们分离职责。
二、开放封闭原则（ＯＣＰ）
软件实体（类、模块、函数）应该是可扩展的，但是不可修改的。也就是说：对于扩展是开放的，对于更改是封闭的。怎样可能在不改动模块源代码的情况下去更改它的行为呢？怎样才能在无需对模块进行改动的情况下就改变它的功能呢？关键是抽象！因此在进行面向对象设计时要尽量考虑接口封装机制、抽象机制和多态技术。该原则同样适合于非面向对象设计的方法，是软件工程设计方法的重要原则之一。
三、替换原则（ＬＳＰ）
子类应当可以替换父类并出现在父类能够出现的任何地方。这个原则是Liskov于1987年提出的设计原则。它同样可以从Bertrand Meyer 的DBC (Design by Contract〔基于契约设计〕) 的概念推出。
四、依赖倒置原则（ＤＩＰ）
１、高层模块不应该依赖于低层模块。二者都应该依赖于抽象。２、抽象不应该依赖于细节。细节应该依赖于抽象。在进行业务设计时，与特定业务有关的依赖关系应该尽量依赖接口和抽象类，而不是依赖于具体类。具体类只负责相关业务的实现，修改具体类不影响与特定业务有关的依赖关系。在结构化设计中，我们可以看到底层的模块是对高层抽象模块的实现（高层抽象模块通过调用底层模块），这说明，抽象的模块要依赖具体实现相关的模块，底层模块的具体实现发生变动时将会严重影响高层抽象的模块，显然这是结构化方法的一个"硬伤"。面向对象方法的依赖关系刚好相反，具体实现类依赖于抽象类和接口。
五、接口分离原则（ＩＳＰ）
采用多个与特定客户类有关的接口比采用一个通用的涵盖多个业务方法的接口要好。 ISP原则是另外一个支持诸如COM等组件化的使能技术。缺少ISP，组件、类的可用性和移植性将大打折扣。这个原则的本质相当简单。如果你拥有一个针对多个客户的类，为每一个客户创建特定业务接口，然后使该客户类继承多个特定业务接口将比直接加载客户所需所有方法有效。
六、 合成/聚合复用原则（CARP)
在一个新的对象里面使用一些已有的对象，使之成为新对象的一部分；新的对象通过向这些对象的委派达到复用这些对象的目的。
应首先使用合成/聚合，合成/聚合则使系统灵活，其次才考虑继承，达到复用的目的。而使用继承时，要严格遵循里氏代换原则。有效地使用继承会有助于对问题的理解，降低复杂度，而滥用继承会增加系统构建、维护时的难度及系统的复杂度。
如果两个类是“Has-a”关系应使用合成、聚合，如果是“Is-a”关系可使用继承。"Is-A"是严格的分类学意义上定义，意思是一个类是另一个类的"一种"。而"Has-A"则不同，它表示某一个角色具有某一项责任。
七、迪米特法则（LoD)
一个软件实体应当尽可能少的与其他实体发生相互作用。 这样，当一个模块修改时，就会尽量少的影响其他的模块。扩展会相对容易。这是对软件实体之间通信的限制。它要求限制软件实体之间通信的宽度和深度。
另外的六项是关于包的设计原则。在本文中，包是指一个二进制的可发布文件，比如.jar文件、或dll文件，而不是Java包或是C++的命名空间（译注3）。
头三项包原则是关于包内聚性的，它们会告诉我们该把什么划分到包中：
REP，重用发布等价原则，重用的粒度就是发布的粒度。
CCP，共同封闭原则，包中的所有类对于同一类性质的变化应该是共同封闭的。
CRP，共同重用原则，一个包中的所有类应该是共同重用的。
最后的三项原则是关于包之间的耦合性原则的，并且论述了评价系统中包结构优良与否的评判标准。
ADP，无环依赖原则，在包的依赖关系图中不允许存在环。
SDP，稳定依赖原则，朝着稳定的方向进行依赖。
SAP，稳定抽象原则，包的抽象程度应该和其稳定程度一致。
译注：
1，OOD，全称Object Oriented Design，即面向对象设计。
2，PPP，即Bob大叔的著作《敏捷软件开发 原则、模式与实践》一书以及其相关书籍，因都有“原则、模式与实践”，即Priciples, Patterns and Practices，故常简称为PPP。
3，命名空间，原文为namespace，也译作名字空间。它是一种特殊的作用域，它包含了处于该作用域内的所有标示符，且本身也用一个标示符来表示，这样便于将一系列在逻辑上相关的标示符用一个标示符来组织。就Java编程语言来说，命名空间是通过java包来表达的，所有代码都归属与一个包。来自其他包中的代码要通过指定包名来引用某项特定的标示符，例如，包java.lang中的String类要通过java.lang.String的形式引用。在C++中，命名空间常用来避免命名冲突，尽管现今的C++语言对命名空间做出了扩展，但过去的C++代码很少使用此项功能。
（原文链接网址：http://www.butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod; Robert C. Martin的英文blog网址： http://www.butunclebob.com/ArticleS.UncleBob）
作者简介：Robert C. Martin是Object Mentor公司总裁，面向对象设计、模式、UML、敏捷方法学和极限编程领域内的资深顾问。他不仅是Jolt获奖图书《敏捷软件开发：原则、模式与实践》（中文版）（《敏捷软件开发》（英文影印版））的作者，还是畅销书Designing Object-Oriented C++ Applications Using the Booch Method的作者。Martin是Pattern Languages of Program Design 3和More C++ Gems的主编，并与James Newkirk合著了XP in Practice。他是国际程序员大会上著名的发言人，并在C++ Report杂志担任过4年的编辑。
软件业曾经爆发过的所有变革里，其中曾经有两个派系如此广泛的深入人心，它们就是结构化编程和面向对象编程。所有主流的现代编程语言都被它们两个激烈的影响着。实际上，要想不像结构化和面向对象编程的样子来编写程序都是一件难事。我们的主流编程语言都没有goto，因此它们服从了结构化编程中最重要的禁令。我们的大多数主流编程语言都是基于类的，而且不支持在类以外定义函数或是变量，因此也避免了面向对象编程中最容易坠入的陷阱。
用这些编程语言所编写的程序可能看起来是结构化的或是面向对象的，可是“看起来”是会欺骗人的。当今的编程语言经常不顾他们所从属那种派系的编程语言的基本原则。我会在另篇blog中再探讨结构化编程的原则，本篇，我想要谈论的是面向对象编程的基本原则。
在1995年的三月，我写了一篇文章并发表在comp.object上，那是我第一次写OOD（译注1）原则的文章，此后就一发不可收拾的写了很多。你可以在我的PPP一书（译注2）中看到它们，在object mentor的很多文章中也都有，其中就有那篇众所周知的纲要（近期会译为中文，请关注）。
这些原则着重于OOD中的依赖管理方面，而淡化抽象与建模方面。这并不是说OO在抽象方面不够强大，或是OO不适合构建模型。当然有很多人都在使用OO的这些部分，只是这些原则集中关注于依赖管理。
依赖管理是我们每个人都要面对的问题，每当我们在屏幕面前打开那些彼此纠结又令人作呕的代码，我们就会遭受不良的依赖管理所带来的恶果。不良的依赖管理导致代码难以改变，易被破坏，而且不可重用。实际上，我在PPP一书中谈论过很多不同的设计坏味道，而这些都与依赖管理有关。从另一方面来说，如果依赖经过了良性的管理，代码就可以保持灵活性、健壮性和重用性。所以依赖管理和这些相关原则是程序员们渴求的让软件保持优良架构的基石。
头七项原则是关于类设计的，它们是：
SRP，单一职责原则，一个类应该有且只有一个改变的理由。
OCP，开放封闭原则，你应该能够不用修改原有类就能扩展一个类的行为。
LSP，Liskov替换原则，派生类要与其基类自相容。
DIP，依赖倒置原则，依赖于抽象而不是实现。
ISP，接口隔离原则，客户只要关注它们所需的接口。
CARP，合成/聚合复用原则，要尽量使用组合、聚合，而不是继承关系以达到复用的目的
LoD，迪米特法则，一个软件实体应该与尽可能少的其他实体发生互相作用
一、单一职责原则（ＳＲＰ）
就一个类而言，应该仅有一个引起它变化的原因。软件设计真正要做的许多内容，就是发现职责并把那些职责相互分离。测试驱动的开发实践常常会在设计出现臭味之前就迫使我们分离职责。
二、开放封闭原则（ＯＣＰ）
软件实体（类、模块、函数）应该是可扩展的，但是不可修改的。也就是说：对于扩展是开放的，对于更改是封闭的。怎样可能在不改动模块源代码的情况下去更改它的行为呢？怎样才能在无需对模块进行改动的情况下就改变它的功能呢？关键是抽象！因此在进行面向对象设计时要尽量考虑接口封装机制、抽象机制和多态技术。该原则同样适合于非面向对象设计的方法，是软件工程设计方法的重要原则之一。
三、替换原则（ＬＳＰ）
子类应当可以替换父类并出现在父类能够出现的任何地方。这个原则是Liskov于1987年提出的设计原则。它同样可以从Bertrand Meyer 的DBC (Design by Contract〔基于契约设计〕) 的概念推出。
四、依赖倒置原则（ＤＩＰ）
１、高层模块不应该依赖于低层模块。二者都应该依赖于抽象。２、抽象不应该依赖于细节。细节应该依赖于抽象。在进行业务设计时，与特定业务有关的依赖关系应该尽量依赖接口和抽象类，而不是依赖于具体类。具体类只负责相关业务的实现，修改具体类不影响与特定业务有关的依赖关系。在结构化设计中，我们可以看到底层的模块是对高层抽象模块的实现（高层抽象模块通过调用底层模块），这说明，抽象的模块要依赖具体实现相关的模块，底层模块的具体实现发生变动时将会严重影响高层抽象的模块，显然这是结构化方法的一个"硬伤"。面向对象方法的依赖关系刚好相反，具体实现类依赖于抽象类和接口。
五、接口分离原则（ＩＳＰ）
采用多个与特定客户类有关的接口比采用一个通用的涵盖多个业务方法的接口要好。 ISP原则是另外一个支持诸如COM等组件化的使能技术。缺少ISP，组件、类的可用性和移植性将大打折扣。这个原则的本质相当简单。如果你拥有一个针对多个客户的类，为每一个客户创建特定业务接口，然后使该客户类继承多个特定业务接口将比直接加载客户所需所有方法有效。
六、 合成/聚合复用原则（CARP)
在一个新的对象里面使用一些已有的对象，使之成为新对象的一部分；新的对象通过向这些对象的委派达到复用这些对象的目的。
应首先使用合成/聚合，合成/聚合则使系统灵活，其次才考虑继承，达到复用的目的。而使用继承时，要严格遵循里氏代换原则。有效地使用继承会有助于对问题的理解，降低复杂度，而滥用继承会增加系统构建、维护时的难度及系统的复杂度。
如果两个类是“Has-a”关系应使用合成、聚合，如果是“Is-a”关系可使用继承。"Is-A"是严格的分类学意义上定义，意思是一个类是另一个类的"一种"。而"Has-A"则不同，它表示某一个角色具有某一项责任。
七、迪米特法则（LoD)
一个软件实体应当尽可能少的与其他实体发生相互作用。 这样，当一个模块修改时，就会尽量少的影响其他的模块。扩展会相对容易。这是对软件实体之间通信的限制。它要求限制软件实体之间通信的宽度和深度。
另外的六项是关于包的设计原则。在本文中，包是指一个二进制的可发布文件，比如.jar文件、或dll文件，而不是Java包或是C++的命名空间（译注3）。
头三项包原则是关于包内聚性的，它们会告诉我们该把什么划分到包中：
REP，重用发布等价原则，重用的粒度就是发布的粒度。
CCP，共同封闭原则，包中的所有类对于同一类性质的变化应该是共同封闭的。
CRP，共同重用原则，一个包中的所有类应该是共同重用的。
最后的三项原则是关于包之间的耦合性原则的，并且论述了评价系统中包结构优良与否的评判标准。
ADP，无环依赖原则，在包的依赖关系图中不允许存在环。
SDP，稳定依赖原则，朝着稳定的方向进行依赖。
SAP，稳定抽象原则，包的抽象程度应该和其稳定程度一致。
译注：
1，OOD，全称Object Oriented Design，即面向对象设计。
2，PPP，即Bob大叔的著作《敏捷软件开发 原则、模式与实践》一书以及其相关书籍，因都有“原则、模式与实践”，即Priciples, Patterns and Practices，故常简称为PPP。
3，命名空间，原文为namespace，也译作名字空间。它是一种特殊的作用域，它包含了处于该作用域内的所有标示符，且本身也用一个标示符来表示，这样便于将一系列在逻辑上相关的标示符用一个标示符来组织。就Java编程语言来说，命名空间是通过java包来表达的，所有代码都归属与一个包。来自其他包中的代码要通过指定包名来引用某项特定的标示符，例如，包java.lang中的String类要通过java.lang.String的形式引用。在C++中，命名空间常用来避免命名冲突，尽管现今的C++语言对命名空间做出了扩展，但过去的C++代码很少使用此项功能。
（原文链接网址：http://www.butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod; Robert C. Martin的英文blog网址： http://www.butunclebob.com/ArticleS.UncleBob）
作者简介：Robert C. Martin是Object Mentor公司总裁，面向对象设计、模式、UML、敏捷方法学和极限编程领域内的资深顾问。他不仅是Jolt获奖图书《敏捷软件开发：原则、模式与实践》（中文版）（《敏捷软件开发》（英文影印版））的作者，还是畅销书Designing Object-Oriented C++ Applications Using the Booch Method的作者。Martin是Pattern Languages of Program Design 3和More C++ Gems的主编，并与James Newkirk合著了XP in Practice。他是国际程序员大会上著名的发言人，并在C++ Report杂志担任过4年的编辑。
内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理 
相关文章推荐
- 面向对象设计的11原则
- 面向对象设计的11原则--你称得上OO专家么？
- 面向对象设计的11原则
- 面向对象设计的11原则
- 面向对象设计的11原则
- 面向对象设计的11原则
- 面向对象设计的11原则
- 面向对象设计的11原则
- 面向对象设计的11原则
- 面向对象设计的11原则
- 面向对象设计的11原则--你称得上OO专家么?
- 面向对象设计的11原则
- 面向对象设计的11原则--你称得上OO专家么？
- 第二章 【面向对象设计原则】
- 面向对象设计原则
- 面向对象设计原则之二--里氏代换原则
- 面向对象设计原则之三--依赖倒置(转)原则
- JAVA进阶 面向对象程序设计——第5周 设计原则（耦合和聚合，代码结构设计，程序维护拓展发展）
- 面向对象设计原则及设计模式概要
- 面向对象设计原则