|
|
本文是從 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 頁
好萊塢原則
不要調用我，我會調用你的。
不要自我重復(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)
不要添加你“認為以后可能有用”的代碼。只在“事到臨頭”時才添加代碼。
簡單化，傻瓜化(KISS)
讓它能工作的最簡單的方法是什么？
- http://c2.com/cgi/wiki?DoTheSimplestThingThatCouldPossiblyWork
- http://en.wikipedia.org/wiki/KISS_principle
it知識庫：S.O.L.I.D.類設計原則，轉載需保留來源！
鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。
