面向對象程式設計的六大原則(1)-單一職責原則

前言

在網上有很多文章講這是“設計模式六大原則”，也有人講這是“面向對象程式設計的六大原則”，我更傾向于後者。假設一個程式員不懂設計模式或者一個簡單的、開發周期極短的程式可以犧牲設計模式帶來的可擴充性， 而避免設計模式帶來的 複雜性時，他在做面向對象設計的時候依然需要這些原則，是以本質上這并不是設計模式的六大原則，而是面向對象設計的六大原則。當然我們無論是在學習面向對象分析與設計，還是在學習設計模式前，都需要知道這些原則，從學習設計模式的角度上來看，叫做“設計模式六大原則”也不算錯。

這六個原則常被叫做SOLID原則：

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

開放-關閉原則,OCP(Open-Close Principle)

裡氏替換原則,LSP(Liskov Substitution Principle)

接口隔離原則,ISP(Interface Segregation Principle)

依賴倒置原則,DIP(Dependence Inversion Principle)

最少知識原則,LKP(Least Knowledge Principle),又稱迪米特法則,LOD(Law Of Demeter)

本文主要闡述"單一職責原則“(Single Resonpisibility Principle):

定義：

就一個類而言，應該僅有一個引起它變化的原因。通俗點地說就是不存在多個原因使得一個類發生變化，也就是說一個類隻負責一種職責工作。

需要說明的是單一職責原則不隻是面向對象程式設計思想所特有的，隻要是子產品化的程式設計，都适用單一職責原則。

問題由來：

類T負責兩個不同的職責：職責P1，職責P2。當由于職責P1需求發生改變而需要修改類T時，有可能會導緻原本運作正常的職責P2功能發生故障。

解決方案：

       遵循單一職責原則。分别建立兩個類T1、T2，使T1完成職責P1功能，T2完成職責P2功能。這樣，當修改類T1時，不會使職責P2發生故障風險；同理，當修改T2時，也不會使職責P1發生故障風險。

關于職責：

單一職責原則的難點是在于職責範圍的認定。關于職責的認定是一個仁者見仁智者見智的話題，在實際開發中也會引起程式員之間的争論。有的人認為這些功能方法的實作目的很相似，必須要放在一個類中，有的人認為方法差别很大，必須要分拆成多個類，在多個類裡面來實作。

還有職責的擴散問題。軟體一開發完上線後并不是一成不變的，随着社會的進步，需求的變更，軟體的功能可能要做些維護更改，有時候會遇到職責擴散。所謂的職責擴散就是因為某種原因，職責R被分化為粒度更細的R1和R2。比如類C隻負責一個職責R，這是符合單一職責原則的。但是後來需要把職責R拆分為職責R1和職責R2，那麼這時候是否需要死守着單一職責原則，把類C也拆開為C1和C2。接着如果R1又需要細化為R11和R12呢……在程式已經寫好的情況下，一味的遵守單一職責原則，不停的分拆類所付出的開銷是很大的。這時候就涉及到平衡的問題，平衡單一職責原則與修改造成的開銷的平衡。在職責擴散到我們無法控制的程度之前，立刻對代碼進行重構。

遵循單一職責的優點有:

• 提高了代碼的可讀性。一個類簡單了，可讀性自然就提高了。
• 提高了系統的可維護性。代碼的可讀性高了，并且修改一項職責對其他職責影響降低了，可維護性自然就提高了。
• 變更引起的風險變低了。單一職責最大的優點就是修改一個功能，對其他功能的影響顯著降低。