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

　　英文原文：S.O.L.I.D. Class Design Principles