物件導向五大原則

沒有規矩，不成方圓！物件導向亦是如此！

五大原則讓物件導向技術更加規範，讓我們深入了解一下！

就乙個類而言，應該僅有乙個引起它變化的原因。

是盡量能讓類的變化減少，乙個類做好自己的本職工作就好了，別操太多的心，從而減少職責耦合！防止設計時產生一些不必要的問題！

類的職責分離是我們在程式設計的時候，需要去考慮的問題！如果職責太集中的話，很容易牽一髮而動全身！

軟體實體（類、模組、函式等）應該可以擴充套件，但是不可以修改。

其實單看名字的話，會不會有些矛盾呢？既要開發又要封閉的；但是一看解釋就一目了然了。開發是對模組功能擴充套件來說的，而封閉是對模組功能修改來說的，就好比你買了乙個自行車，你感覺它的功能不夠強大，你可以給它安裝各種配件（開放）使其功能更加強大，但是不能把它車軲轆拆下來（封閉）！

但是我們在開發的時候，不可能保證自己的類不會發生變化，設計的類不可能完全封閉，就像自行車廠商不可能設計出一種自行車能夠滿足所有人的需求，所以我們要事先對可能會發生變化的種類進行猜測，然後構造抽象（類或是方法）來隔離那些變化！

我們應該僅僅對那些頻繁發生變化的類做出抽象，所以不是抽象的類越多越好，要根據實際情況，在做決定！

1.高層模組不應該依賴底層模組，兩個都應該依賴抽象.

抽象不應該依賴細節。細節應該依賴抽象這句話的意思就是，我們在製造硬體的時候，不要針對某一塊主機板製造，如果有一天，這個主機板公司倒閉了，那麼你的硬體設施不就都涼涼了嘛！我們針對主機板和硬體的介面製造，那麼之後只要有用這種介面的主機板，你的硬體都能買的出去！

2.抽象不應該依賴細節。細節應該依賴抽象

抽象不應該依賴細節。細節應該依賴抽象這句話的意思就是，面對介面程式設計，不面對實現程式設計（不要想太多），就像你有乙份工作，不要去想你是去給誰做，你要把它做好然後收到相應的報酬就ok了！

此原則是物件導向設計的標誌，我們在時間程式設計中會深深的感受到它無處不在！

子類必須能偶替換掉它們的父型別。

在乙個程式中，用其子類替換掉它的父類，程式不僅可以正常執行，而且沒有任何察覺！

這裡我們經常會說的乙個例子，那就是企鵝和鳥：

我的理解：

動物鳥評判標準

是否屬於鳥類

企鵝會飛

不屬於企鵝

體均被羽，恆溫，卵生

屬於這個**代表了我的思維，企鵝屬不屬於鳥類，關鍵在於鳥類是如何定義的！

#迪公尺特法則

它也叫最少知識原則，如果兩個類不必彼此直接通訊，那麼這兩個類就不應當放生直接的相互作用。如果其中乙個類需要直接呼叫另一類的某乙個方法的話，可以通過第三者**這個呼叫！

它的前提，也是我們在程式設計是需要注意的乙個點，就是盡量降低類成員的訪問許可權，包裝好自己的private狀態！有需要公開的字段，就通過屬性的形式進行體現，不僅降低類之間的耦合程度，還讓資料更加安全！

我的理解就是，兩個人能不說話就不說話，如果必須說，可以通過和兩個人都熟悉的人（第三者）進行間接溝通，從而減少兩個人之間的交集（耦合）！

（沒有分享的原則，我會根據具體的設計模式和大家分享！）

原則是思想的體現，也是行為的規範！

所以我們不僅需要知道，還要做到！

let』s go！

物件導向 五大原則