Java成長第五集--面向對象設計的五大原則

S.O.L.I.D 是面向對象設計(OOD)和麪向對象編程(OOP)中的幾個重要編碼原則(Programming Priciple)的首字母縮寫。如下圖說明：

下面就我的的理解來講說這五大原則的含義究竟是什麼？

1、單一職責：  咱們一般都說「低耦合，高內聚」。在我看來，這裏的"單一職責"就是咱們一般所說的「高內聚」，即一個類只完成它應該完成的職責，不能推諉責任，也不可越殂代皰，不能成爲無所不能的上帝類。若是你的團隊中實施寬鬆的「代碼集體全部權」，在編碼的過程當中出現許多人同時修改（維護）同一個類的現象，並且成員之間的溝通不夠及時，主動和暢通的話，那麼時間一長，就極可能出現「承擔過多職責」的上帝類。這時，提煉基類/接口和提煉類重構將能幫助咱們消除或減輕這種設計臭味。

 

2、開放封閉原則：從面向對象設計角度看，這個原則能夠這麼理解："軟件實體(類,模塊,函數等等)應當對擴展開放，對修改閉合。" 通俗來說，它意味着你（或者類的客戶）應當能在不修改一個類的前提下擴展這個類的行爲。在OOD裏，對擴展開放意味着類或模塊的行爲可以改變，在需求變化時咱們能以新的，不一樣的方式讓模塊改變，或者在新的應用中知足需求。也就是說，對擴展是開放的，而對修改是封閉的。咱們一般都說：向系統中增長功能時應該只是添加新代碼，而應該儘可能少的修改原代碼。在我看來，這就是遵循開放封閉原則所能帶來的效果。

 

3、里氏替換原則（LSP）："子類型必須可以替換它們的基類型。"或者換個說法："使用基類引用的地方必須能使用繼承類的對象而沒必要知道它。" 這個原則正是保證繼承可以被正確使用的前提。一般咱們都說，「優先使用組合（委託）而不是繼承」或者說「只有在肯定是 is-a 的關係時才能使用繼承」，由於繼承常常致使」緊耦合「的設計。在基本的面向對象原則裏，"繼承"一般是"is a"的關係。若是"Developer" 是一個"SoftwareProfessional",那麼"Developer"類應當繼承"SoftwareProfessional"類。在類設計中"Is a"關係很是重要，但它容易衝昏頭腦，致使使用錯誤的繼承形成錯誤設計。例如：鳥都有一種行爲fly，翠鳥和鴕鳥都繼承自鳥，可是卻不可以在使用鳥類的地方用鴕鳥來進行替換，由於鴕鳥不會飛，因此這就違背了里氏替換原則。

爲何LSP如此重要？

• 若是沒有LSP，類繼承就會混亂；若是子類做爲一個參數傳遞給方法，將會出現未知行爲；
• 若是沒有LSP，適用與基類的單元測試將不能成功用於測試子類；

 

4、接口分離原則（ISP）：這個原則的意思是"客戶端不該該被迫依賴於它們不用的接口。" 也就是說，一個接口或者類應該擁有儘量少的行爲（那麼，什麼叫儘量少？就是少到剛好能完成它自身的職責），這也是保證「軟件系統模塊的粒度儘量少，以達到高度可重用的目的。接口包含太多的方法會下降其可用性，像這種包含了無用方法的"胖接口"會增長類之間的耦合。若是一個類想實現該接口,那麼它須要實現全部的方法,儘管有些對它來講可能徹底沒用，因此這樣作會在系統中引入沒必要要的複雜度，下降代碼的可維護性或魯棒性。接口分離原則確保實現的接口有它們共同的職責,它們是明確的,易理解的,可複用的。

 

5、依賴倒置原則（DIP）：這個原則的意思是：高層模塊不該該依賴底層模塊，二者都應該依賴其抽象。其實又是」面向接口編程，不要面向實現編程「的內在要求。