今天這篇文章，就來給大家講一講關(guān)于面向?qū)ο蟮囊恍┦?，希望能對大家有所幫助?/p>

什么是面向?qū)ο螅?/p>

面向?qū)ο缶褪前焉钪幸鉀Q的問題都用對象的方式進行存儲–把所有的數(shù)據(jù)用屬性、方法表現(xiàn)出來。

面向?qū)ο缶幊叹褪蔷幊痰臅r候數(shù)據(jù)結(jié)構(gòu)（數(shù)據(jù)組織方式 ）都通過對象的結(jié)構(gòu)進行存儲，使用屬性和方法組織起來。對象之間的互動是通過方法的調(diào)用完成互動。

對象的描述方式更加貼合真實世界，有利于對大型業(yè)務(wù)的理解，具有多人合作方便、減少代碼的冗余、靈活性高、代碼的可重用性發(fā)揮到極致、可擴展性等優(yōu)勢。

五大設(shè)計原則——SOLID

學習面向?qū)ο缶幊滔瘛俺橄蟆?、“封裝”、“多態(tài)”、“繼承” 等基礎(chǔ)知識是重要的，但同時為了創(chuàng)建簡潔、模塊化的設(shè)計，了解這些設(shè)計原則也同等重要。

接下來，本文就為大家介紹面向?qū)ο笤O(shè)計的5個基本原則：

S – 單一功能原則（SRP）

O – 開閉原則（OCP）

L – 里氏替換原則（LSP）

I – 接口隔離原則（DIP）

D – 依賴倒置原則（OCP）

單一職責原則

單一職責有兩個含義：一個是避免相同的職責分散到不同的類中， 別一個是避免一個類承擔太多職責。

遵守SPR原則的優(yōu)勢：

●減少類之間的耦合：當需求變化時，只修改一個類，從而隔離了變化帶來類對其他職責的影響

●提高類的復用性：按需引用，一個類負責一個職責，需求的變動只需要修改對應的類或增加某一職責

●降低類的復雜度：職責單一，功能分散開降低一個類多個職責類的復雜度

不遵守SRP會影響對類的復用性。當只需要用該類的某一個職責時，由于它和其他的職責耦合在一起，也就很難分離出。

代碼示例：

開閉原則

對象和實體應該對擴展開放，但是對修改關(guān)閉。

簡單的說就是，一個類應該不用修改其自身就能很容易擴展其功能。

比如：一個網(wǎng)絡(luò)模塊，原來只服務(wù)端功能，而現(xiàn)在要加入客戶端功能，那么應當在不用修改服務(wù)端功能代碼的前提下，就能夠增加客戶端功能的實現(xiàn)代碼，這要求在設(shè)計之初，就應當將服務(wù)端和客戶端分開，公共部分抽象出來。

代碼示例：

里氏替換原則

如果對每一個類型為 T1的對象 o1，都有類型為 T2 的對象o2，使得以 T1定義的所有程序 P 在所有的對象 o1 都代換成 o2 時，程序 P 的行為沒有發(fā)生變化，那么類型 T2 是類型 T1 的子類型。

這句定義的意思是說：每個子類或者衍生類可以毫無問題地替代基類/父類。

這就好比：公司搞年度晚會，所有員工可以參加抽獎，那么不管是老員工還是新員工，也不管是總部員工還是外派員工，都應當可以參加抽獎，否則這公司就不和諧了。

代碼示例：

接口隔離原則

接口隔離原則是指：客戶端不應該被強制去實現(xiàn)于它不需要的接口。

有一個清晰的例子來說明示范這條原則。當一個類需要一個大量的設(shè)置項，為了方便不會要求客戶端去設(shè)置大量的選項，因為在通常他們不需要所有的設(shè)置項。使設(shè)置項可選有助于我們避免產(chǎn)生“胖接口”。

代碼示例：

依賴倒置原則

這條原則說明兩個基本的要點：

●高階的模塊不應該依賴低階的模塊，它們都應該依賴于抽象

●抽象不應該依賴于實現(xiàn)，實現(xiàn)應該依賴于抽象

這條起初看起來有點晦澀難懂，但是如果你使用過PHP框架(例如 Symfony)，你應該見過依賴注入(DI)對這個概念的實現(xiàn)。雖然它們不是完全相通的概念，依賴倒置原則使高階模塊與低階模塊的實現(xiàn)細節(jié)和創(chuàng)建分離。可以使用依賴注入(DI)這種方式來實現(xiàn)它。更多的好處是它使模塊之間解耦。耦合會導致你難于重構(gòu)，它是一種非常糟糕的的開發(fā)模式。

代碼示例：

總結(jié)

面向?qū)ο笤O(shè)計需要遵守如上原則，不過實際的代碼設(shè)計一定要簡單、簡單、簡單。在實際編碼中要根據(jù)情況進行取舍，一味遵守原則，而不注重實際情況的話，可能會讓你的代碼變的難以理解