單一職責原則和實體類別

Question

關於單一責任原則以及無處不在的關於太大類的警告，這些如何適用於實體類？根據其本質，實體是不是應該把所有關於一個實體的東西都包含在一起？這不是他們的「單一責任」嗎？否則，假設你的實體類正在變得像某些人所說的「太大」，你將如何在不破壞該實體應該提供的自然封裝的情況下真正分解它？如果你有一個Person類，只有一個名字，年齡和最喜歡的食物，那麼顯然它們都應該是Person的屬性。但是，如果您需要添加20個更多類似的屬性，如眼睛顏色，isRightHanded，ReligionOfChoice等？正因爲他們中有很多人，突然之間意味着他們需要分成不同的班級嗎？對於「Properties1To5」和「Properties6To10」有一個單獨的類，然後用這些類組合Person類似乎很愚蠢？

或者是否更正確的做法是在Person類中直接保存100個屬性（理論上這兩個屬性可能彼此不相關，除非它們屬於Person），因爲Person類的單一職責是封裝一個人的一切？

Answer 1

如果你看看一些編碼標準文檔，你可能會遇到「類應該不大於'x'方法」的說法。這些「標準」存在良好信仰但沒有太大的用處。這個想法是阻止開發人員創建8000行，單一的，一勞永逸的類。我知道，我以前看過它，這很可怕。但是，限制「每個類的方法數量」，或者在您的示例中，「每個POCO的propeties數量」可能會混淆事物。實際上，以「每個類不超過30個方法」（例如，什麼？）爲例，由於30個方法的限制，您最終得到碎片化的類純粹爲。這實際上使事情更糟糕。

班級應該和他們的一樣大，需要是。這真的歸結於您的應用程序的設計和要求。我該如何真的需要知道一個人，以及我的要求領域內的什麼？如果我需要100個屬性，並且業務規則需要記錄這些屬性中的每一個屬性，並且它們用於報告和/或業務邏輯，那麼有意義的是，您的Person具有100個屬性。將它們拆分成塊就會混淆數據，混淆代碼並使事情變得噩夢。

這就是說，有些時候你可能想把某些特徵分成與我們主人Person POCO相關的其他類。你提到宗教是一種屬性，也許在商業應用中是必要的。但是，如果你的申請的重點是弄清楚人們是如何隨着時間的推移改變他們的宗教信仰的，那麼它是否成爲Person的一部分是沒有意義的呢？我們突然現在有一個ReligionInstance POCO，它在特定時間點上記錄他們的信念。我確信你可以看到我要去哪裏，因爲我肯定有100個屬性 - 根據項目的需要 - 其他屬性可能會被分隔到自己的對象中，因爲這就是邏輯需要。例如，很容易添加地址所需的7/8字段。聽起來不錯，很好，很容易。 但是，如果該人移動，我們沒有記錄他們以前的位置。突然地址看起來像是一個很好的候選人，如果我們關心他們移動到，他們會轉移到自己的對象並鏈接回人。

當您提及撰寫時，我會以同樣的方式思考 - 因爲您將要創建的對象是其他信息的複合材料。如果我們想象我們存儲Person，並且我們還存儲一個或多個Address POCO。根據業務邏輯，我可能只想要這個人，或者我可能希望他們的地址爲和。

這就是我所說的合成。我們的數據庫有我們的Person和我們的Address，我們有一個非數據庫POCO，稱爲PersonWithAddresses（例如），它會給我們的人的信息和他們的地址。業務規則定義了這些對象，我認爲PersonWithAddresses是一個組合。

現在這裏的東西，什麼樣的存儲庫處理這個？我們可能會有一個PersonRepository和一個AddressRepository，他們都爲他們各自的POCO負責。可能我們還有一個CompositePerson存儲庫，使用這兩個存儲庫來構建一個更重量級的POCO，它擁有我們需要的所有信息？我們正在遵守單一責任模式。當我們需要的時候，我們保持輕量級的東西，並且沒有什麼比更適合。