本文是由敏捷宣言簽署人之一、《?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

反向依賴原則(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定律

也被稱做封鎖信息原則：只跟朋友交流

一個對象O的任何一個方法M只能調用下列類型的對象的方法：

• 它自己
• 它的參量
• 它創建/實例化的對象
• 它的直接組件對象

參考

• 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

轉自：http://www.aqee.net/s-o-l-i-d-class-design-principles/

轉載于:https://www.cnblogs.com/hnrainll/archive/2012/11/29/2794175.html

總結

以上是生活随笔為你收集整理的S.O.L.I.D.类设计原则的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。