1. 什麼是單一職責原則
顧名思義就是一個職責嘛，完整的來說，就是一個接口、類和方法負責的功能是單一的，簡單的。
2. 生活中的運用
其實，咱們生活中，有很多這樣的例子，就拿手機廠商造手機來說，爲了完成一部手機的製造，需要有生產cpu的、生產顯示屏的、生產主板的、生產外殼的、生產麥克風的…各種的機器。那麼每一種類型的機器就會生產這一類產品，不會生產其他的產品，這種進行單一產品生產的功能，就是單一職責的具體表現。
3. 這種原則的優點
那麼爲什麼要這麼做呢？當然不是喫飽了撐的，下面就來看看這樣做有什麼好處。
* 降低類的複雜性，有什麼樣的職責都是清晰明確的。
* 可讀性提高，複雜性降低，可維護性提高。
* 應對將來變更的風險能力提高。
咱們就來反面來驗證這3個優點，假如製造手機是一個牛掰的機器，這邊把原料放進去，另外一邊手機就出來了，那麼這臺機器就包含了很多的功能，生產cpu，生產顯示器等等，全一機器幹了，可想而知這臺機器裏面將是多麼的複雜，假如這臺機器生產外殼的功能壞掉了，那麼這個龐大的機器將不能繼續生產手機了，只能等待維修人員了，如果按照單一職責的機器來進行生產，那麼我只要將生產外殼的機器換掉，就可以繼續生產手機，這樣應對風險的能力將大大提高，另外就拿後期的維修機器來說，單一職責的機器維修的效率也是很高的。
4. 菜鳥時代的Activity
當年寫Activity的時候，會把對View的操作，對數據的處理，以及和其他Activity的交互邏輯全都寫到一個Activity裏面，到最後這個Activity一共1000行代碼，當然也有比這還多的，於是吭哧吭哧把這樣的功能完成了，這個時候產品經理說：“小王，這個功能目前有點變動，換成XXX這樣的。”，估計，你當時掐死產品經理的心都有，算了，爲了珍惜生命，也是就忍了，就開始默默的修改龐大的Activity，以及與之相關的類，等你改好了，發給測試，測試人員說：
沒辦法誰叫他是產品經理的呢，就需要改動很多的代碼，一旦發生了bug，還需要從前往後的排查，兼職讓人苦不堪言，那麼在看看現在的MVP這個結構，不就這種單一職責的原理嘛，各自負責各自的，雖然類的數量增加了，但是結構條理清楚，面對將來業務的修改也是很方便，找bug也不費事了，最重要的是團隊的分工合作。
5. 思考
理論是枯燥的，但是將理論和生活結合在一起，將大大提高對理論的理解。