維根斯坦說世界可以分解為事實,而事實又分解為原子事實,原子事實(由物件組成)不可再分.那這裡很明顯的就是我們無法有乙個標準來確定啥是原子事實.有些人覺得乙個原子事實實際上可以再分,另一些人可能覺得不可分。架構不斷
srp(single responsibilities principle)的定義：就乙個類而言，應該僅有乙個引起它變化的原因。簡而言之，就是功能要單一。
what:單一職責
什麼是單一職責原則：單一職責就是乙個類只負責一項職責。當乙個類有多個職責時就可能需要重構這個類了。
why該原則提出了對物件職責的一種理想期望。物件不應該承擔太多職責，正如人不應該一心分為二用。唯有專注，才能保證物件的高內聚；唯有單一，才能保證物件的細粒度。物件的高內聚與細粒度有利於物件的重用和以後的擴充套件。
how類ｔ負責兩個不事的職責：職責ｐ１、職責ｐ２。當由於職責ｐ１需求發生改變而需要修改類ｔ時，有可能會導致原來執行的職責ｐ２功能發生故障。解決方法：分別建立兩個類完成對應的功能。
在實際工作中，單一職責是有利於類的拓展，也為專案架構的演進過程中提供了良好的支援，也提公升了**效率和風險控制，在實際專案中比較常見的現象就是，兩個模組之間都有相同功能aclass，但是這兩個功能是不同開發人員來開發的，在小公司技術不成熟的負責人精力有限的情況下，這個功能就會重複開發兩遍，其實這最重要的，重要的是在將來模組都更換了模組負責人以後功能的調整，會出現兩個模組的不一致，也容易bug的只修復乙個地方，另外乙個地方的遺漏。
public
class
sputils
public
static sputils getinstant()
return sputils;
}}
public
class
sputils
public
static
synchronized sputils getinstant()
return sputils;
}}
public
class sputils
public
static sputils getinstant() }}
return sputils;
}}
public
class
sputils
public
static sputils getinstant()
}
public
class sputils
public
static sputils getinstant()
private
static
class layzsputils
}
設計模式原則 單一職責原則
定義 乙個物件應該只包含單一的職責，並且該職責被完整地封裝在乙個類中。即 不要存在多於乙個導致類變更的原因。通俗的說，就是乙個類只負責一項職責。問題由來 類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...