S.O.L.I.D.类设计原则

2021年09月15日 阅读数:1
这篇文章主要向大家介绍S.O.L.I.D.类设计原则,主要内容包括基础应用、实用技巧、原理机制等方面,希望对大家有所帮助。

本文是由敏捷宣言签署人之1、《 Clean Code(代码整洁之道)》一书的做者Robert C. Martin为他的《Applying Principles and Patterns》这本书搜集整理而来。html

单一责任原则(SRP)

只有一个理由去修改一个类。例如,若是一个业务规则的改变会致使这个类的修改,那么,数据库、界面、报表格式或系统任何其它的部分的改变都不应迫使这个类作修改。java

  • http://davidhayden.com/blog/dave/archive/2005/05/29/1066.aspx
  • http://c2.com/cgi/wiki?SingleResponsibilityPrinciple
  • 《Head First 设计模式》 第 185, 336, 339, 367 页
  • http://msdn.microsoft.com/en-us/magazine/cc546578.aspx
  • http://codebetter.com/blogs/david_laribee/archive/2008/09/09/why-solid-gimme-an-s.aspx

开发/关闭原则(OCP)

软件构成(类,模块,方法等)向扩展行为开放,向修改行为关闭。程序员

  • http://davidhayden.com/blog/dave/archive/2005/06/04/1096.aspx
  • http://en.wikipedia.org/wiki/Open/closed_principle
  • 《Head First 设计模式》第 86-87, 407 页
  • http://c2.com/cgi/wiki?OpenClosedPrinciple
  • http://codebetter.com/blogs/david_laribee/archive/2008/09/11/why-solid-gimme-an-quot-o-quot.aspx

Liskov替换原则(LSP)

子类必须可以用来看成基类使用。若是类A继承类B,任何能使用A的地方,B也一样可使用。例如,是否还记得,正方形能够看做是矩形!当进行扩展时:前提条件不准绕过,后置条件不能放宽限制,可见常量不能被修改(?)。常量:在扩展以前或以后,用户都须要依靠这个常量来传递信息。正确的使用set形式的继承关系。不遵照set语义是很是危险的。概括:使用超类的引用的任何上下文中也可使用其子类的引用替代。这个原则极大的限制了在纯扩展(继承)机制里能够作的事情。不遵照会带来风险。数据库

  • http://davidhayden.com/blog/dave/archive/2005/06/10/1226.aspx
  • 《敏捷软件开发——原则、模式与实践》 页码 ?
  • http://c2.com/cgi/wiki?LiskovSubstitutionPrinciple
  • http://en.wikipedia.org/wiki/Liskov_substitution_principle
  • http://javaboutique.internet.com/tutorials/JavaOO/
  • http://codebetter.com/blogs/david_laribee/archive/2008/09/22/why-solid-gimme-an-l.aspx

接口分离原则(ISP)

一个类对另外一个类的依赖应该限制在最小化的接口上。编程

  • http://davidhayden.com/blog/dave/archive/2005/06/15/1482.aspx
  • http://c2.com/cgi/wiki?InterfaceSegregationPrinciple
  • http://www.google.com/search?q=interface+segration+principle
  • http://doodleproject.sourceforge.net/articles/2001/interfaceSegregationPrinciple.html

反向依赖原则(DIP)

依赖抽象层(接口),而不是具体类。设计模式

  • http://davidhayden.com/blog/dave/archive/2005/06/10/1261.aspx
  • http://en.wikipedia.org/wiki/Dependency_inversion_principle
  • 《Head First 设计模式》第 139-143 页
  • http://c2.com/cgi/wiki?DependencyInversionPrinciple
其它重要原则

Demeter定律

也被称作封锁信息原则:只跟朋友交流ide

一个对象O的任何一个方法M只能调用下列类型的对象的方法:google

  • 它本身
  • 它的参量
  • 它建立/实例化的对象
  • 它的直接组件对象

参考.net

  • http://en.wikipedia.org/wiki/Principle_of_Least_Knowledge
  • http://ctrl-shift-b.blogspot.com/2008/06/distilling-law-of-demeter.html
  • 《Head First 设计模式》第 265 页

好莱坞原则

不要调用我,我会调用你的。设计

  • http://en.wikipedia.org/wiki/Hollywood_Principle
  • 《Head First 设计模式》第 296 页

不要自我重复(DRY)

去掉重复代码。

  • 《程序员修炼之道》(Pragmatic Programmer) 第 27 页
  • http://en.wikipedia.org/wiki/Don%27t_repeat_yourself
  • http://c2.com/cgi/wiki?DontRepeatYourself

对接口编程,而不是对实现

反向依赖的另一种说法。

  • 《Head First 设计模式》第 11, 110-111, 243, 335 页
  • http://www.artima.com/lejava/articles/designprinciples.html

你不须要它(YAGNI)

不要添加你“认为之后可能有用”的代码。只在“事到临头”时才添加代码。

  • http://c2.com/xp/YouArentGonnaNeedIt.html
  • http://en.wikipedia.org/wiki/You_Ain%27t_Gonna_Need_It

简单化,傻瓜化(KISS)

让它能工做的最简单的方法是什么?

  • http://c2.com/cgi/wiki?DoTheSimplestThingThatCouldPossiblyWork
  • http://en.wikipedia.org/wiki/KISS_principle