SOLID (面向对象设计) From 维基百科

http://zh.wikipedia.org/wiki/SOLID_(%E9%9D%A2%E5%90%91%E5%AF%B9%E8%B1%A1%E8%AE%BE%E8%AE%A1)

 

在 程序设计领域， SOLID (单一功能、开闭原则、里氏替换、接口隔离以及依赖反转)是由罗伯特•C•马丁在21世纪早期[1] 引入的记忆术首字母缩略字[2][3]，指代了面向对象编程和面向对象设计的五个基本原则。当这些原则被一起应用时，它们使得一个程序员开发一个容易进行软件维护和扩展的系统变得更加可能。[1] SOLID所包含的原则是通过引发编程者进行软件源代码的代码重构进行软件的代码异味清扫，从而使得软件清晰可读以及可扩展时可以应用的指南。SOLID被典型的应用在测试驱动开发上，并且是敏捷开发以及自适应软件开发的基本原则的重要组成部分。[1][4]

概述[编辑]

首字母指代概念
S 单一功能原则
单一功能原则
认为对象应该仅具有一种单一功能的概念。
O 开闭原则
开闭原则
认为“软件体应该是对于扩展开放的，但是对于修改封闭的”的概念。
L 里氏替换原则
里氏替换原则
认为“程序中的对象应该是可以在不改变程序正确性的前提下被它的子类所替换的”的概念。参考 契约式设计。
I 接口隔离原则
接口隔离原则
认为“多个特定客户端接口要好于一个宽泛用途的接口”[5] 的概念。
D 依赖反转原则
依赖反转原则
认为一个方法应该遵从“依赖于抽象而不是一个实例”[5] 的概念。 依赖注入是该原则的一种实现方式。

参考[编辑]

基本概念以及相关主题[编辑]

设计和开发原则[编辑]

引用[编辑]

  1. ^ 1.0 1.1 1.2 “SOLID Object-Oriented Design”, Sandi Metz (Duke University), Talk given at the 2009 Gotham Ruby Conference in May, 2009. Last verified 2009-01-15.
  2. ^ “Principles Of OOD”, Robert C. Martin (“Uncle Bob”), butunclebob.com, Last verified 2009-01-14. (Note the “first five principles”, though the acronym is not used in this article.) Dates back to at least 2003.
  3. ^ “Getting a SOLID start.”, Robert C. Martin (“Uncle Bob”), objectmentor.com. Last verified 2009-01-14.
  4. ^ “Introducing SOLID Object-Oriented Design Principles and Microsoft Unity”, Uwe Schmitz, Presentation given at the Regina .NET User Group in May, 2009. Last verified 2009-01-14.
  5. ^ 5.0 5.1 “Design Principles and Design Patterns”, Robert C. Martin (“Uncle Bob”), objectmentor.com. Last verified 2009-01-14.

 

在面向对象编程领域中，单一功能原则（Single responsibility principle）规定每个类都应该有一个单一的功能，并且该功能应该由这个类完全封装起来。所有它的（这个类的）服务都应该严密的和该功能平行（功能平行，意味着没有依赖）。

这个术语由罗伯特·C·马丁（Robert Cecil Martin）在他的《敏捷软件开发，原则，模式和实践》一书中的一篇名为〈面向对象设计原则〉的文章中给出。 [1] 马丁表述该原则是基于的《结构化分析和系统规格》[2]一书中的内聚原则（Cohesion）上。

马丁把功能（职责）定义为：“改变的原因”，并且总结出一个类或者模块应该有且只有一个改变的原因。一个具体的例子就是，想象有一个用于编辑和打印报表的模块。这样的一个模块存在两个改变的原因。第一，报表的内容可以改变（编辑）。第二，报表的格式可以改变（打印）。这两方面会的改变因为完全不同的起因而发生：一个是本质的修改，一个是表面的修改。单一功能原则认为这两方面的问题事实上是两个分离的功能，因此他们应该分离在不同的类或者模块里。把有不同的改变原因的事物耦合在一起的设计是糟糕的。

保持一个类专注于单一功能点上的一个重要的原因是，它会使得类更加的健壮。继续上面的例子，如果有一个对于报表编辑流程的修改，那么将存在极大的危险性，打印功能的代码会因此不工作，假使这两个功能存在于同一个类中的话。（http://zh.wikipedia.org/wiki/%E5%8D%95%E4%B8%80%E5%8A%9F%E8%83%BD%E5%8E%9F%E5%88%99）

 

在面向对象编程领域中，开闭原则规定“软件中的对象（类，模块，函数等等）应该对于扩展是开放的，但是对于修改是封闭的”[1]，这意味着一个实体是允许在不改变它的源代码的前提下变更它的行为。该特性在产品化的环境中是特别有价值的，在这种环境中，改变源代码需要代码审查，单元测试以及诸如此类的用以确保产品使用质量的过程。遵循这种原则的代码在扩展时并不发生改变，因此无需上述的过程。

开闭原则的命名被应用在两种方式上。这两种方式都使用了继承来解决明显的困境，但是它们的目的，技术以及结果是不同的。

梅耶开闭原则[编辑]

勃兰特·梅耶一般被认为是最早提出开闭原则这一术语的人，[來源請求]在他1988年发行的《面向对象软件构造》中给出。这一想法认为一旦完成，一个类的实现只应该因错误而修改，新的或者改变的特性应该通过新建不同的类实现。新建的类可以通过继承的方式来重用原类的代码。衍生的子类可以或不可以拥有和原类相同的接口。

梅耶的定义提倡实现继承。具体实现可以通过继承方式来重用，但是接口规格不必如此。已存在的实现对于修改是封闭的，但是新的实现不必实现原有的接口。

多态开闭原则[编辑]

在20世纪90年代，开闭原则被广泛的重新定义由于抽象化接口的使用，在这中间实现可以被改变，多种实现可以被创建，并且多态化的替换不同的实现。

相比梅耶的使用方式，多态开闭原则的定义倡导对抽象基类的继承。接口规约可以通过继承来重用，但是实现不必重用。已存在的接口对于修改是封闭的，并且新的实现必须，至少，实现那个接口。

罗伯特·C·马丁1996年发表的文章《开闭原则》[2]是使用这种方法的启发式著作。在2001年，Craig Larman把开闭原则关联到了Alistair Cockburn的名为受护的变量的模式以及David Parnas关于信息隐藏的讨论。[3]

http://zh.wikipedia.org/wiki/%E5%BC%80%E9%97%AD%E5%8E%9F%E5%88%99

 

在面向对象的程序设计中，里氏替换原则（Liskov Substitution principle）是对子类型的特别定义。它由芭芭拉·利斯科夫（Barbara Liskov）在1987年在一次会议上名为“数据的抽象与层次”的演说中首先提出。[1]

里氏替换原则的内容可以描述为： “派生类（子类）对象能够替换其基类（超类）对象被使用。” 以上内容并非利斯科夫的原文，而是译自罗伯特·马丁（Robert Martin）对原文的解读。其原文为：

Let q(x) be a property provable about objects x of type T. Then q(y) should be true for objects y of type Swhere S is a subtype of T.
http://zh.wikipedia.org/wiki/%E9%87%8C%E6%B0%8F%E6%9B%BF%E6%8D%A2%E5%8E%9F%E5%88%99

在面向对象编程领域中，依赖反转原则（Dependency inversion principle）指代了一种特定的解耦（传统的依赖关系建立在高层次上，而具体的策略设置则应用在低层次的模块上）形式。在这种形势下，为了使得高层次的模块不依赖于低层次的模块的实现细节的目的，依赖模块被颠倒了（例如：反转）。该原则规定：

  1. 高层次的模块不应该依赖于低层次的模块，两者都应该依赖于抽象接口。
  2. 抽象接口不应该依赖于具体实现。而具体实现则应该依赖于抽象接口。

该原则颠倒了一部分人对于面向对象设计的认识方式，比如高层次和低层次对象都应该应该依赖于相同的抽象接口。[1]

描述[编辑]

在传统的应用架构中，低层次的组件设计用于被高层次的组件使用，这一点提供了逐步的构建一个复杂系统的可能。在这种结构下，高层次的组件直接依赖于低层次的组件去实现一些任务。这种对于低层次组件的依赖限制了重用高层次组件的可行性。

依赖反转原则的目的在把高层次组件从低层次组件中解耦出来，这样使得重用不同的低层组件实现变得可能。把高层组件和低层组件划分到不同的包/库（在这些包/库中拥有定义了高层组件所必须的行为和服务的接口，并且存在高层组件的包）中的方式促进了这中解耦。由低层组件对于高层组件接口的具体实现要求低层组件包的编译是依赖于高层组件的，因此颠倒了传统的依赖关系。众多的设计模式，比如插件，服务定位器或者依赖反转，则被用来在运行时把指定的低层组件实现提供给高层组件。

应用依赖反转原则同样被认为是应用了适配器模式，例如：高层的类定义了它自己的适配器接口（高层类所依赖的抽象接都）。被适配的对象同样依赖于适配器接口的抽象（这是当然的，因为它实现了这个接口），同时它的实现则可以使用它自身所在低层模块的代码。通过这种方式，高层组件则不依赖于低层组件，因为它（高层组件）仅间接的通过调用配置器接口多态方法的方式使用了低层组件通过适配器接口，在这些多态方法则是由被适配对象以及它的低层模块所实现的。

历史[编辑]

依赖反转原则由罗伯特·C·马丁（Robert Cecil Martin）提出，并且在数篇公开著作中被表述，包括论文《面向对象设计质量标准：对于依赖的分析》[2]，以及一篇1996年出现在C++报道中的名为《依赖反转原则》的文章[3]，和《敏捷软件开发，原则，模式和实践》，《C#中的敏捷原则，模式和实践》两本书。

参见[编辑]

引用[编辑]

  1. ^ Freeman, Eric; Freeman, Elisabeth; Kathy, Sierra; Bert, Bates. In Hendrickson, Mike. Head First Design Patterns (paperback) 1. O'REILLY. 2004 [2012-06-21].ISBN 978-0-596-00712-6 （English）. |editor1-last=和|editor-last=只需其一 (帮助); |editor1-first=和|editor-first=只需其一 (帮助)
  2. ^ Object Oriented Design Quality Metrics: an analysis of dependencies Robert C. Martin, C++ Report, Sept/Oct 1995
  3. ^ The Dependency Inversion Principle, Robert C. Martin, C++ Report, May 1996

外部链接[编辑]

posted @ 2013-09-23 11:22  @妞儿  阅读(1210)  评论(0)  编辑  收藏  举报