官术网_书友最值得收藏!

  • 設計模式之禪
  • 秦小波
  • 1848字
  • 2019-01-02 03:55:44

1.2 絕殺技,打破你的傳統思維

解釋到這里,估計你已經很不屑了,“切!這么簡單的東西還要講?!”好,我們來講點復雜的。SRP的原話解釋是:

There should never be more than one reason for a class to change.

這句話初中生都能看懂,不多說,但是看懂是一碼事,實施就是另外一碼事了。上面講的例子很好理解,在實際項目中大家都已經這么做了,那我們再來看看下面這個例子是否好理解。電話這玩意,是現代人都離不了,電話通話的時候有4個過程發生:撥號、通話、回應、掛機,那我們寫一個接口,其類圖如圖1-4所示。

我不是有意要冒犯IPhone的,同名純屬巧合,我們來看一個這個過程的代碼,如代碼清單1-2所示。

圖1-4 電話類圖

代碼清單1-2 電話過程

public interface IPhone {
     //撥通電話
     public void dial(String phoneNumber);
     //通話
     public void chat(Object o);
     //通話完畢,掛電話
     public void hangup();
}

實現類也比較簡單,我就不再寫了,大家看看這個接口有沒有問題?我相信大部分的讀者都會說這個沒有問題呀,以前我就是這么做的呀,某某書上也是這么寫的呀,還有什么什么的源碼也是這么寫的!是的,這個接口接近于完美,看清楚了,是“接近”!單一職責原則要求一個接口或類只有一個原因引起變化,也就是一個接口或類只有一個職責,它就負責一件事情,看看上面的接口只負責一件事情嗎?是只有一個原因引起變化嗎?好像不是!

IPhone這個接口可不是只有一個職責,它包含了兩個職責:一個是協議管理,一個是數據傳送。dial()和hangup()兩個方法實現的是協議管理,分別負責撥號接通和掛機;chat()實現的是數據的傳送,把我們說的話轉換成模擬信號或數字信號傳遞到對方,然后再把對方傳遞過來的信號還原成我們聽得懂的語言。我們可以這樣考慮這個問題,協議接通的變化會引起這個接口或實現類的變化嗎?會的!那數據傳送(想想看,電話不僅僅可以通話,還可以上網)的變化會引起這個接口或實現類的變化嗎?會的!那就很簡單了,這里有兩個原因都引起了類的變化。這兩個職責會相互影響嗎?電話撥號,我只要能接通就成,甭管是電信的還是網通的協議;電話連接后還關心傳遞的是什么數據嗎?通過這樣的分析,我們發現類圖上的IPhone接口包含了兩個職責,而且這兩個職責的變化不相互影響,那就考慮拆分成兩個接口,其類圖如圖1-5所示。

這個類圖看上去有點復雜了,完全滿足了單一職責原則的要求,每個接口職責分明,結構清晰,但是我相信你在設計的時候肯定不會采用這種方式,一個手機類要把ConnectionManager和DataTransfer組合在一塊才能使用。組合是一種強耦合關系,你和我都有共同的生命期,這樣的強耦合關系還不如使用接口實現的方式呢,而且還增加了類的復雜性,多了兩個類。經過這樣的思考后,我們再修改一下類圖,如圖1-6所示。

圖1-5 職責分明的電話類圖

圖1-6 簡潔清晰、職責分明的電話類圖

這樣的設計才是完美的,一個類實現了兩個接口,把兩個職責融合在一個類中。你會覺得這個Phone有兩個原因引起變化了呀,是的,但是別忘記了我們是面向接口編程,我們對外公布的是接口而不是實現類。而且,如果真要實現類的單一職責,這個就必須使用上面的組合模式了,這會引起類間耦合過重、類的數量增加等問題,人為地增加了設計的復雜性。

通過上面的例子,我們來總結一下單一職責原則有什么好處:

?類的復雜性降低,實現什么職責都有清晰明確的定義;

?可讀性提高,復雜性降低,那當然可讀性提高了;

?可維護性提高,可讀性提高,那當然更容易維護了;

?變更引起的風險降低,變更是必不可少的,如果接口的單一職責做得好,一個接口修改只對相應的實現類有影響,對其他的接口無影響,這對系統的擴展性、維護性都有非常大的幫助。

看過電話這個例子后,是不是想反思一下了,我以前的設計是不是有點問題了?不,不是的,不要懷疑自己的技術能力,單一職責原則最難劃分的就是職責。一個職責一個接口,但問題是“職責”沒有一個量化的標準,一個類到底要負責那些職責?這些職責該怎么細化?細化后是否都要有一個接口或類?這些都需要從實際的項目去考慮,從功能上來說,定義一個IPhone接口也沒有錯,實現了電話的功能,而且設計還很簡單,僅僅一個接口一個實現類,實際的項目我想大家都會這么設計。項目要考慮可變因素和不可變因素,以及相關的收益成本比率,因此設計一個IPhone接口也可能是沒有錯的。但是,如果純從“學究”理論上分析就有問題了,有兩個可以變化的原因放到了一個接口中,這就為以后的變化帶來了風險。如果以后模擬電話升級到數字電話,我們提供的接口IPhone是不是要修改了?接口修改對其他的Invoker類是不是有很大影響?

注意 單一職責原則提出了一個編寫程序的標準,用“職責”或“變化原因”來衡量接口或類設計得是否優良,但是“職責”和“變化原因”都是不可度量的,因項目而異,因環境而異。

主站蜘蛛池模板: 昭平县| 法库县| 饶阳县| 浦东新区| 斗六市| 四平市| 高密市| 昭觉县| 石柱| 青冈县| 漠河县| 栖霞市| 紫金县| 开阳县| 南阳市| 平江县| 凌云县| 柘城县| 仁寿县| 芦山县| 临澧县| 公主岭市| 新营市| 镇江市| 舒城县| 尉犁县| 汶川县| 宿州市| 二手房| 织金县| 旌德县| 金沙县| 甘南县| 裕民县| 塔河县| 遂宁市| 肇州县| 青田县| 田阳县| 宜君县| 教育|