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

导读：本文是从 S.O.L.I.D. Class Design Principles 这篇文章翻译而来。

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

单一责任原则(SRP)

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

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