1. 程式人生 > >面向對象七大原則

面向對象七大原則

聲明 倒置 基本 depend 原因 父類繼承 現在 我們 mod

面向對象的七大原則分別是:單一職責,裏氏替換,迪米特法則,依賴倒轉,接口隔離,合成/聚合原則,開放-封閉

1.開閉原則(Open-Closed Principle, OCP)

定義:軟件實體應當對擴展開放,對修改關閉。這句話說得有點專業,更通俗一點講,也就是:軟件系統中包含的各種組件,例如模塊(Modules)、類(Classes)以及功能(Functions)等等,應該在不修改現有代碼的基礎上,去擴展新功能。開閉原則中原有“開”,是指對於組件功能的擴展是開放的,是允許對其進行功能擴展的;開閉原則中“閉”,是指對於代碼的修改是封閉的,即不應該修改原有的代碼。

問題由來:凡事的產生都有緣由。我們來看看,開閉原則的產生緣由。在軟件的生命周期內,因為變化、升級和維護等原因需要對軟件原有代碼進行修改時,可能會給舊代碼中引入錯誤,也可能會使我們不得不對整個功能進行重構,並且需要原有代碼經過重新測試。這就對我們的整個系統的影響特別大,這也充分展現出了系統的耦合性如果太高,會大大的增加後期的擴展,維護。為了解決這個問題,故人們總結出了開閉原則。解決開閉原則的根本其實還是在解耦合。所以,我們面向對象的開發,我們最根本的任務就是解耦合。

解決方法:當軟件需要變化時,盡量通過擴展軟件實體的行為來實現變化,而不是通過修改已有的代碼來實現變化。

小結:開閉原則具有理想主義的色彩,說的很抽象,它是面向對象設計的終極目標。其他幾條原則,則可以看做是開閉原則的實現。我們要用抽象構建框架,用實現擴展細節。

2.單一職責原則(Single Responsibility Principle

定義:一個類,只有一個引起它變化的原因。即:應該只有一個職責。

每一個職責都是變化的一個軸線,如果一個類有一個以上的職責,這些職責就耦合在了一起。這會導致脆弱的設計。當一個職責發生變化時,可能會影響其它的職責。另外,多個職責耦合在一起,會影響復用性。例如:要實現邏輯和界面的分離。需要說明的一點是單一職責原則不只是面向對象編程思想所特有的,只要是模塊化的程序設計,都需要遵循這一重要原則。

問題由來:類T負責兩個不同的職責:職責P1,職責P2。當由於職責P1需求發生改變而需要修改類T時,有可能會導致原本運行正常的職責P2功能發生故障

解決方法:分別建立兩個類T1、T2,使T1完成職責P1功能,T2完成職責P2功能。這樣,當修改類T1時,不會使職責P2發生故障風險;同理,當修改T2時,也不會使職責P1發生故障風險

3. 裏氏替換原則(Liskov Substitution Principle)

定義:子類型必須能夠替換掉它們的父類型。註意這裏的能夠兩字。有人也戲稱老鼠的兒子會打洞原則。

問題由來:有一功能P1,由類A完成。現需要將功能P1進行擴展,擴展後的功能為P,其中P由原有功能P1與新功能P2組成。新功能P由類A的子類B來完成,則子類B在完成新功能P2的同時,有可能會導致原有功能P1發生故障。

解決方法:類B繼承類A時,除添加新的方法完成新增功能P2外,盡量不要重寫父類A的方法,也盡量不要重載父類A的方法

小結:所有引用父類的地方必須能透明地使用其子類的對象。子類可以擴展父類的功能,但不能改變父類原有的功能,即:子類可以實現父類的抽象方法,子類也中可以增加自己特有的方法,但不能覆蓋父類的非抽象方法。當子類的方法重載父類的方法時,方法的前置條件(即方法的形參)要比父類方法的輸入參數更寬松。當子類的方法實現父類的抽象方法時,方法的後置條件(即方法的返回值)要比父類更嚴格。

4. 迪米特法則(Law Of Demeter)

定義:迪米特法則又叫最少知道原則,即:一個對象應該對其他對象保持最少的了解。如果兩個類不必彼此直接通信,那麽這兩個類就不應當發生直接的相互作用。如果其中一個類需要調用另一個類的某一個方法的話,可以通過第三者轉發這個調用。簡單定義為只與直接的朋友通信。首先來解釋一下什麽是直接的朋友:每個對象都會與其他對象有耦合關系,只要兩個對象之間有耦合關系,我們就說這兩個對象之間是朋友關系。耦合的方式很多,依賴、關聯、組合、聚合等。其中,我們稱出現成員變量、方法參數、方法返回值中的類為直接的朋友,而出現在局部變量中的類則不是直接的朋友。也就是說,陌生的類最好不要作為局部變量的形式出現在類的內部。

問題由來:類與類之間的關系越密切,耦合度越大,當一個類發生改變時,對另一個類的影響也越大。

最早是在1987年由美國Northeastern University的Ian Holland提出。通俗的來講,就是一個類對自己依賴的類知道的越少越好。也就是說,對於被依賴的類來說,無論邏輯多麽復雜,都盡量地的將邏輯封裝在類的內部,對外除了提供的public方法,不對外泄漏任何信息。迪米特法則還有一個更簡單的定義:只與直接的朋友通信。

解決方法:盡量降低類與類之間的耦合。 自從我們接觸編程開始,就知道了軟件編程的總的原則:低耦合,高內聚。無論是面向過程編程還是面向對象編程,只有使各個模塊之間的耦合盡量的低,才能提高代碼的復用率。

迪米特法則的初衷是降低類之間的耦合,由於每個類都減少了不必要的依賴,因此的確可以降低耦合關系。但是凡事都有度,雖然可以避免與非直接的類通信,但是要通信,必然會通過一個“中介”來發生聯系。故過分的使用迪米特原則,會產生大量這樣的中介和傳遞類,導致系統復雜度變大。所以在采用迪米特法則時要反復權衡,既做到結構清晰,又要高內聚低耦合。

5. 依賴倒置原則(Dependence Inversion Principle)

定義:高層模塊不應該依賴低層模塊,二者都應該依賴其抽象;抽象不應該依賴細節;細節應該依賴抽象。中心思想是面向接口編程

問題由來:類A直接依賴類B,假如要將類A改為依賴類C,則必須通過修改類A的代碼來達成。這種場景下,類A一般是高層模塊,負責復雜的業務邏輯;類B和類C是低層模塊,負責基本的原子操作;假如修改類A,會給程序帶來不必要的風險。

解決方法:將類A修改為依賴接口I,類B和類C各自實現接口I,類A通過接口I間接與類B或者類C發生聯系,則會大大降低修改類A的幾率。

在實際編程中,我們一般需要做到如下3點:

1). 低層模塊盡量都要有抽象類或接口,或者兩者都有。

2). 變量的聲明類型盡量是抽象類或接口。

3). 使用繼承時遵循裏氏替換原則。

采用依賴倒置原則尤其給多人合作開發帶來了極大的便利,參與協作開發的人越多、項目越龐大,采用依賴導致原則的意義就越重大。

小結:依賴倒置原則就是要我們面向接口編程,理解了面向接口編程,也就理解了依賴倒置。

6. 接口隔離原則(Interface Segregation Principle)

定義:客戶端不應該依賴它不需要的接口;一個類對另一個類的依賴應該建立在最小的接口上。

問題由來:類A通過接口I依賴類B,類C通過接口I依賴類D,如果接口I對於類A和類B來說不是最小接口,則類B和類D必須去實現他們不需要的方法

解決方法:1、 使用委托分離接口。2、 使用多重繼承分離接口。3.將臃腫的接口I拆分為獨立的幾個接口,類A和類C分別與他們需要的接口建立依賴關系。也就是采用接口隔離原則。

小結:我們在代碼編寫過程中,運用接口隔離原則,一定要適度,接口設計的過大或過小都不好。對接口進行細化可以提高程序設計靈活性是不掙的事實,但是如果過小,則會造成接口數量過多,使設計復雜化。所以一定要適度。設計接口的時候,只有多花些時間去思考和籌劃,就能準確地實踐這一原則。

7. 合成/聚合原則(Composite/Aggregate Reuse Principle,CARP)

定義:也有人叫做合成復用原則,及盡量使用合成/聚合,盡量不要使用類繼承。換句話說,就是能用合成/聚合的地方,絕不用繼承。

為什麽要盡量使用合成/聚合而不使用類繼承?

1. 對象的繼承關系在編譯時就定義好了,所以無法在運行時改變從父類繼承的子類的實現

2. 子類的實現和它的父類有非常緊密的依賴關系,以至於父類實現中的任何變化必然會導致子類發生變化

3. 當你復用子類的時候,如果繼承下來的實現不適合解決新的問題,則父類必須重寫或者被其它更適合的類所替換,這種依賴關系限制了靈活性,並最終限制了復用性。

總結:這些原則在設計模式中體現的淋淋盡致,設計模式就是實現了這些原則,從而達到了代碼復用、增強了系統的擴展性。所以設計模式被很多人奉為經典。我們可以通過好好的研究設計模式,來慢慢的體會這些設計原則。

面向對象七大原則