單一職責原則(srp:single responsibility principle),它規定乙個類應該只有乙個發生變化的原因。所謂職責是指類變化的原因。如果乙個類有多於乙個的動機被改變,那麼這個類就具有多於乙個的職責。而單一職責原則就是指乙個類或者模組應該有且只有乙個改變的原因。
單一職責原則的好處:
● 類的複雜性大大降低,每個類都有清楚的定義。
● 提高可讀性。
● 維護性高。
● 變更時風險率降低。
轉化到android開發中也就是我們編寫的介面、類、方法要使用單一職責原則,下面通過這三個方面來詳細了解一下單一職責原則。
public
inte***ce weather
從介面本身來看寫的沒問題,但是從單一職責原則的角度上看是有問題的,介面裡展示了兩個職責,乙個是載入資料,乙個是提示資訊。再換個角度想,相互不影響的方法可以拆分成多個介面,那我們來看getweatehrsuccess()和getweathererror(throwable e),如果其中一方發生變化了,那麼另一方肯定發生變化了 ;那麼loadweather(string date,string city)和其他兩個方法比較會發現相互不影響。所以loadweather(string date,string city)可以單獨拆分出來。
所以介面要符合單一職責。
比如乙個修改使用者名稱和密碼的需求,我們把它寫在乙個方法裡.
上述**的方法職責不明確,既有修改使用者名稱又修改位址,不符合單一職責原則。每個方法必須的職責必須清晰明確,不僅開發簡單,而且維護也很容易。
正確的修改如下:
類的單一職責原則和介面、方法的單一職責一樣的,但是我們會發現先在專案開發中很多類都不太符合,那是因為類的單一職責受很多因素的影響,比如說專案的週期、技術人員的水平等等。
所以總結起來,在開發中,定義的介面和方法一定要做到單一職責,類要視情況而定。
我的交流圈如下-希望大家多多支援
六大設計原則詳解 1 單一職責原則
單一職責原則 srp single responsibility principle 它規定乙個類應該只有乙個發生變化的原因。所謂職責是指類變化的原因。如果乙個類有多於乙個的動機被改變,那麼這個類就具有多於乙個的職責。而單一職責原則就是指乙個類或者模組應該有且只有乙個改變的原因。單一職責原則的好處 ...
六大設計原則 單一職責原則
這裡的職責是指類變化的原因,單一職責原則規定乙個類應該有且僅有乙個引起它變化的原因,否則類應該被拆分。該原則提出物件不應該承擔太多職責,如果乙個物件承擔了太多的職責,至少存在以下兩個缺點 1.乙個職責的變化可能會削弱或者抑制這個類實現其他職責的能力 2.當客戶端需要該物件的某乙個職責時,不得不將其他...
六大設計原則之單一職責原則
單一職責原則指乙個類應當只負責一件事情。單一職責原則本質上是在提高類的內聚性。帶來的好處有 結合業務去審視類的定義,使類與業務實體相對應。該場景根據筆者看到的真實案例改寫而成。場景描述 一年級做了一次語文模擬考試。現在有如下三個需求 找出得100分的學生 找出分數在 90,100 的學生 找出分數是...