呵呵，好久沒寫了。因為前段時間心情不是很好，並且各種事情比較多、比較忙。因此。。。就一直拖到現在了。
今天很輕鬆，先準備一下回來的預熱吧。學習的是單一職責模式。定義如下。
單一職責原則（srp single responsibility principle）,就乙個類而言。應該僅有乙個引起它變化的原因。
也就是說，盡量使得類的功能盡可能簡單，不將具有多個功能的處理方法放在乙個類中。就好像是前些年的照相手機，因為各種因素的原因，具有照相功能的手機往往啥功能都做不好。手機功能一般，攝像頭極爛。除非付出極大的代價。
這就是單一職責模式的典型反面教材。因而那些年，甚至到現在nokia一直專注於提公升手機的通訊功能而不是照相功能（雖然有6500s，n系列這樣的照相手機，但是是少數）。
ps：即使到現在，我一直偏向於把手機和相機分開。
因此，依據單一職責原則，應當盡量讓類不要承擔太多的職責，減少類裡面的功能耦合。
這一小節純理論，而且難度不高。很輕鬆，呵呵：）
設計模式原則 單一職責原則
定義 乙個物件應該只包含單一的職責，並且該職責被完整地封裝在乙個類中。即 不要存在多於乙個導致類變更的原因。通俗的說，就是乙個類只負責一項職責。問題由來 類t負責兩個不同的職責 職責p1，職責p2。當由於職責p1需求發生改變而需要修改類t時，有可能會導致原本執行正常的職責p2功能發生故障。解決方案 ...
設計模式原則 單一職責原則
對類來說的，即乙個類應該只負責一項職責。假如類a負責多項職責，當其中一項職責需求發生變更時，可能對其他職責的執行造成影響。例如 類a負責實現 訂單資料持久化 職責 和 使用者資料持久化 職責，那麼當我們需要修改 使用者資料持久化 需求時，由於 糅雜在乙個類裡，可能會對 訂單資料持久化 的職責造成影響...
設計模式原則 單一職責原則
1.概念 對類來說的，即乙個類應該只負責一項職責。如類a負責兩個不同職責 職責1，職責2。當職責1需求變更而改變a時，可能造成職責2執行錯誤，所以需要將類a的粒度分解為a1，a2。2.問題的提出 package com.atguigu.principle.singleresponsibility p...