原則一:單一職責原則(SRP),就一個類而言,應該引用一個引起它變換的原因。具體就是盡量簡化類的方法。通俗的說,即一個類只負責一項職責。
具體可見:http://blog.csdn.net/zhengzhb/article/details/7278174這的講解非常詳細。
原則二:開放-封閉原則,是說軟體實體(類/模組/函數等等),應該可以擴充,但是不可修改。
對於程式設計而言,怎麼的設計才能面對需求的改變卻可以保持相對的穩定,從而可以使得系統可以再第一個版本的基礎上不斷的推出新版本呢?
答案是應用該原則。
既然,需求不可能不變,並且設計也不可能考慮那麼全面。但是我們要盡量保證類設計的很好,當新功能來了,只需要增加類,而不是要修改類。但是並不能預Crowdsourced Security Testing道哪些功能是可以被隔離的,但是我們盡量做到封閉-開放。
如果在最開始的時候,設計的類,需要發生變化,增加一個功能,則在這裡需要考慮重構原來的代碼,隔離也就是建立抽象。
比如,設計了一個加法演算法,當來了一個需求是要減法時,我們就考慮設計一個繼承了。
開放封閉原則是物件導向的核心所在,遵循這個原則可以帶來物件導向所謂的巨大好處,也就是可維護,可擴充,可複用,靈活性好。然而,對於應用程式中的每個部分都刻意的抽象同樣不是一個i好主意,拒絕不成熟的抽象和抽象一樣重要。
原則三:依賴到轉原則 這個原則看了一邊大話設計模式後感覺有些雲裡霧裡的。拋開書就只還記得一個執行個體,為什麼我們會修電腦這麼複雜的東西,而不會修收音機這個相對簡單的東西呢?原因可能是intel這些公司在設計電腦的時候是“針對介面編程的,而不是針對實現編程”。記憶體壞了,我們只要拔下來換一塊就好了,硬碟不夠了,只需要插一個移動硬碟就ok。 這裡用到一個原則------
裡氏代換原則。說白了,就是一個軟體實體如果需要一個父類的話,那麼一定適用於其子類,而它覺察不出父類對象和子類對象的區別。 即,子類型必須能夠替換掉他們的父類型。 書上舉了個例子,即企鵝不能繼承鳥類,因為企鵝不會飛,而鳥會飛。
正是由於子類型的可替換性才使得使用父類型的模組在無需修改的情況下就可以擴充。 下面是前輩的總結,出自http://blog.csdn.net/zhengzhb/article/details/7289269定義:高層模組不應該依賴低層模組,二者都應該依賴其抽象;抽象不應該依賴細節;細節應該依賴抽象。
問題由來:類A直接依賴類B,假如要將類A改為依賴類C,則必須通過修改類A的代碼來達成。這種情境下,類A一般是高層模組,負責複雜的商務邏輯;類B和類C是低層模組,負責基本的原子操作;假如修改類A,會給程式帶來不必要的風險。
解決方案:將類A修改為依賴介面I,類B和類C各自實現介面I,類A通過介面I間接與類B或者類C發生聯絡,則會大大降低修改類A的幾率。
原則四:迪米特法則定義:一個對象應該對其他對象保持最少的瞭解。
問題由來:類與類之間的關係越密切,耦合度越大,當一個類發生改變時,對另一個類的影響也越大。
解決方案:盡量降低類與類之間的耦合。
自從我們接觸編程開始,就知道了軟體編程的總的原則:低耦合,高內聚。無論是面向過程編程還是物件導向編程,只有使各個模組之間的耦合盡量的低,才能提高代碼的複用率。低耦合的優點不言而喻,但是怎麼樣編程才能做到低耦合呢?那正是迪米特法則要去完成的。
迪米特法則又叫最少知道原則,最早是在1987年由美國Northeastern University的Ian Holland提出。通俗的來講,就是一個類對自己依賴的類知道的越少越好。也就是說,對於被依賴的類來說,無論邏輯多麼複雜,都盡量地的將邏輯封裝在類的內部,對外除了提供的public方法,不對外泄漏任何資訊。迪米特法則還有一個更簡單的定義:只與直接的朋友通訊。首先來解釋一下什麼是直接的朋友:每個對象都會與其他對象有耦合關係,只要兩個對象之間有耦合關係,我們就說這兩個對象之間是朋友關係。耦合的方式很多,依賴、關聯、組合、彙總等。其中,我們稱出現成員變數、方法參數、方法傳回值中的類為直接的朋友,而出現在局部變數中的類則不是直接的朋友。也就是說,陌生的類最好不要作為局部變數的形式出現在類的內部。
來自:http://blog.csdn.net/zhengzhb/article/details/7296930
總結下這四個原則吧。 1.類的功能盡量單一,不要太多功能。(防止方法1變了,影響方法2的功能。) 2.設計類時,考慮到新功能增加後,不虛改現有的類,而是增加類,重構抽象和繼承,來完成功能。(防止版本更新,修改工作巨大) 3.繼承時,父類的方法完全是子類的方法,而子類的方法全部繼承於父類,這樣父類則相當於介面,降低了,子類與其他類間的耦合。(調用時,只調用父類)