本文是從 S.O.L.I.D. Class Design Principles 這篇文章翻譯而來。

　　本文是由敏捷宣言簽署人之一、《 Clean Code(代碼整潔之道)》一書的作者Robert C. Martin為他的《Applying Principles and Patterns》這本書搜集整理而來。

　　單一責任原則(SRP)

　　只有一個理由去修改一個類。例如，如果一個業(yè)務規(guī)則的改變會導致這個類的修改，那么，數(shù)據庫、界面、報表格式或系統(tǒng)任何其它的部分的改變都不該迫使這個類做修改。

• 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

　　開發(fā)/關閉原則(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
• 《敏捷軟件開發(fā)——原則、模式與實踐》頁碼 ?
• 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只能調用下列類型的對象的方法：

• 它自己
• 它的參量
• 它創(chuàng)建/實例化的對象
• 它的直接組件對象

　　參考

• 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

　　對接口編程，而不是對實現(xiàn)

　　反向依賴的另外一種說法。

• 《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

it知識庫：S.O.L.I.D.類設計原則，轉載需保留來源！

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。