閱讀936 返回首頁    go Php編程


PHP代碼簡潔之道——SOLID原則

SOLID 是Michael Feathers推薦的便於記憶的首字母簡寫,它代表了Robert Martin命名的最重要的五個麵對對象編碼設計原則

S: 單一職責原則 (SRP)

O: 開閉原則 (OCP)

L: 裏氏替換原則 (LSP)

I: 接口隔離原則 (ISP)

D: 依賴反轉原則 (DIP)

單一職責原則 Single Responsibility Principle (SRP)

"修改一個類應該隻為一個理由"。人們總是易於用一堆方法塞滿一個類,如同我們在飛機上隻能攜帶一個行李箱(把所有的東西都塞到箱子裏)。這樣做的問題是:從概念上這樣的類不是高內聚的,並且留下了很多理由去修改它。將你需要修改類的次數降低到最小很重要。這是因為,當有很多方法在類中時,修改其中一處,你很難知曉在代碼庫中哪些依賴的模塊會被影響到。

Bad:

Good:

開閉原則 Open/Closed Principle (OCP)

正如Bertrand Meyer所述,"軟件的實體(類, 模塊, 函數,等)應該對擴展開放,對修改關閉。"這個原則是在說明應該允許用戶在不改變已有代碼的情況下增加新的功能。

Bad:

在上麵的代碼中,對於HttpRequester類中的fetch方法,如果我新增了一個新的xxxAdapter類並且要在fetch方法中用到的話,就需要在HttpRequester類中去修改類(如加上一個elseif 判斷),而通過下麵的代碼,就可很好的解決這個問題。下麵代碼很好的說明了如何在不改變原有代碼的情況下增加新功能。

Good:

裏氏替換原則 Liskov Substitution Principle (LSP)

對這個概念最好的解釋是:如果你有一個父類和一個子類,在不改變原有結果正確性的前提下父類和子類可以互換。這個聽起來讓人有些迷惑,所以讓我們來看一個經典的正方形-長方形的例子。從數學上講,正方形是一種長方形,但是當你的模型通過繼承使用了"is-a"的關係時,就不對了。

Bad:

Good:

接口隔離原則

接口隔離原則:"客戶端不應該被強製去實現於它不需要的接口"。

有一個清晰的例子來說明示範這條原則。當一個類需要一個大量的設置項,為了方便不會要求客戶端去設置大量的選項,因為在通常他們不需要所有的設置項。使設置項可選有助於我們避免產生"胖接口"

Bad:

上麵的代碼中,Robot類並不需要eat()這個方法,但是實現了Emplyee接口,於是隻能實現所有的方法了,這使得Robot實現了它並不需要的方法。所以在這裏應該對Emplyee接口進行拆分,正確的代碼如下:

Good:

依賴反轉原則 Dependency Inversion Principle (DIP)

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

高階的模塊不應該依賴低階的模塊,它們都應該依賴於抽象

抽象不應該依賴於實現,實現應該依賴於抽象

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

Bad:

Good:

別寫重複代碼 (DRY)

這條原則大家應該都是比較熟悉了。

盡你最大的努力去避免複製代碼,它是一種非常糟糕的行為,複製代碼通常意味著當你需要變更一些邏輯時,你需要修改不止一處。

Bad:

Good:

Very good:

後記:雖然OOP設計需要遵守如上原則,不過實際的代碼設計一定要簡單、簡單、簡單。在實際編碼中要根據情況進行取舍,一味遵守原則,而不注重實際情況的話,可能會讓你的代碼變的難以理解!

技術交流Q群:

聊聊技術+妹紙。

最後更新:2017-10-24 08:14:16

  上一篇:go php新手如何入門
  下一篇:go 商務/前端/PHP/插畫師/運營崗