1. 什么是單一職責原則

顧名思義就是一個職責嘛，完整的來說，就是一個接口、類和方法負責的功能是單一的，簡單的。

2. 生活中的運用

其實，咱們生活中，有很多這樣的例子，就拿手機廠商造手機來說，為了完成一部手機的制造，需要有生產(chǎn)cpu的、生產(chǎn)顯示屏的、生產(chǎn)主板的、生產(chǎn)外殼的、生產(chǎn)麥克風的...各種的機器。那么每一種類型的機器就會生產(chǎn)這一類產(chǎn)品，不會生產(chǎn)其他的產(chǎn)品，這種進行單一產(chǎn)品生產(chǎn)的功能，就是單一職責的具體表現(xiàn)。

3. 這種原則的優(yōu)點

那么為什么要這么做呢？當然不是吃飽了撐的，下面就來看看這樣做有什么好處。

• 降低類的復雜性，有什么樣的職責都是清晰明確的。
• 可讀性提高，復雜性降低，可維護性提高。
• 應對將來變更的風險能力提高。

咱們就來反面來驗證這3個優(yōu)點，假如制造手機是一個牛掰的機器，這邊把原料放進去，另外一邊手機就出來了，那么這臺機器就包含了很多的功能，生產(chǎn)cpu，生產(chǎn)顯示器等等，全一機器干了，可想而知這臺機器里面將是多么的復雜，假如這臺機器生產(chǎn)外殼的功能壞掉了，那么這個龐大的機器將不能繼續(xù)生產(chǎn)手機了，只能等待維修人員了，如果按照單一職責的機器來進行生產(chǎn)，那么我只要將生產(chǎn)外殼的機器換掉，就可以繼續(xù)生產(chǎn)手機，這樣應對風險的能力將大大提高，另外就拿后期的維修機器來說，單一職責的機器維修的效率也是很高的。

4. 菜鳥時代的Activity

當年寫Activity的時候，會把對View的操作，對數(shù)據(jù)的處理，以及和其他Activity的交互邏輯全都寫到一個Activity里面，到最后這個Activity一共1000行代碼，當然也有比這還多的，于是吭哧吭哧把這樣的功能完成了，這個時候產(chǎn)品經(jīng)理說：“小王，這個功能目前有點變動，換成XXX這樣的?！?，估計，你當時掐死產(chǎn)品經(jīng)理的心都有，算了，為了珍惜生命，也是就忍了，就開始默默的修改龐大的Activity，以及與之相關(guān)的類，等你改好了，發(fā)給測試，測試人員說：

沒辦法誰叫他是產(chǎn)品經(jīng)理的呢，就需要改動很多的代碼，一旦發(fā)生了bug，還需要從前往后的排查，兼職讓人苦不堪言，那么在看看現(xiàn)在的MVP這個結(jié)構(gòu)，不就這種單一職責的原理嘛，各自負責各自的，雖然類的數(shù)量增加了，但是結(jié)構(gòu)條理清楚，面對將來業(yè)務的修改也是很方便，找bug也不費事了，最重要的是團隊的分工合作。

5. 思考

理論是枯燥的，但是將理論和生活結(jié)合在一起，將大大提高對理論的理解。