一種理解是：把模組看作比類更加抽象的概念，類也可以看作模組。另一種理解是：把模組看作比類更加粗粒度的**塊，模組中包含多個類，多個類組成乙個模組。
乙個類只負責完成乙個職責或者功能。也就是說，不要設計大而全的類，要設計粒度小、功能單一的類。換個角度來講就是，乙個類包含了兩個或者兩個以上業務不相干的功能，那我們就說它職責不夠單一，應該將它拆分成多個功能更加單
一、粒度更細的類。
乙個類裡既包含訂單的一些操作，又包含使用者的一些操作。而訂單和使用者是兩個獨立的業務領域模型，我們將兩個不相干的功能放到同乙個類中，那就違反了單一職責原則。為了滿足單一職責原則，我們需要將這個類拆分成兩個粒度更細、功能更加單一的兩個類：訂單類和使用者類
publicclass
userinfo
上面類 可以說是滿足單一模式 因為位址 是使用者資訊的一部分,也可以說不是 需要拆分成useraddress 獨立出來
評價乙個類是否單一 並沒有非常明確的,可以量化的指標。在設計時我們可以先設計出乙個粗粒度的類 在後期隨著業務擴充套件的時候再進行拆分，比如上面例子，業務擴充套件出另外乙個子系統 需要使用者支援共享和新增位址資訊。
/*** protocol format: identifier-string;
* for example: ueueue; */
public
class
serialization
public string serialize(mapobject)
public mapdeserialize(string text)
string gsonstr =text.substring(identifier_string.length());
return gson.fromjson(gsonstr, map.class
); }
}
將序列化後反序列化拆分成2個類
publicclass
serializer
public string serialize(mapobject)
}public
class
deserializer
public mapdeserialize(string text)
string gsonstr =text.substring(identifier_string.length());
return gson.fromjson(gsonstr, map.class
); }
}
可能出現的問題是 序列化協議又json改為xml 但反序列化類也要隨著修改 如果漏掉修改就會出序列化失敗的問題 導致，拆分之後，**的可維護性變差了。
類中的**行數、函式或者屬性過多；類依賴的其他類過多，或者依賴類的其他類過多；私有方法過多；比較難給類起乙個合適的名字；類中大量的方法都是集中操作類中的某幾個屬性。
設計原則之美學習筆記 設計原則
乙個類只負責完成乙個職責或者功能。不要設計大而全的類，要設計粒度小 功能單一的類。單一職責原則是為了實現 高內聚 低耦合，提高 的復用性 可讀性 可維護性。不同的應用場景 不同階段的需求背景 不同的業務層面，對同乙個類的職責是否單一，可能會有不同的判定結果。實際上，一些側面的判斷指標更具有指導意義和...
設計模式之單一職責原則學習
單一職責原則 就乙個類而言應該僅有乙個引起它變化的原因。比如寫乙個視窗應用程式。我們會建立乙個類，將各種各樣的 如某種演算法的 或是訪問資料庫的 都放在這個類中。以後一旦需求有所更改就必須修改這個類。各個功能的耦合性太大，牽一髮而動全身。維護很麻煩，復用不可能，也缺乏靈活性。由於c 語言是我的第一門...
設計模式學習之單一職責原則
乙個產品簡單一些，職責單一一些，或許是更好的選擇。乙個類而言，應該僅有乙個引起它變化的原因。打個比方，我們在新建乙個winform應用程式的時候，就會有個form類自動生成，那麼，在這個自動生成的類裡面，我們不能把所有的 都往裡面填，什麼db連線，邏輯層的 等等都往裡面塞。萬一哪天要改個需求，你就得...