什麼是分解的好處，什麼表示一個類應該分解？

Question

我聽過很多關於什麼時候應該分解類的規則（比如你的類變得難以管理），但我不知道這個問題的具體答案。

我不是在尋找「最佳實踐」或「代碼氣味」。例如，如果我看到重複的代碼，我知道有一個特定的解決方案：通過創建基類或其他創建可以使用的單個方法來消除重複的代碼。這是我正在尋找的具體答案的一個例子。

但它不是那麼清楚，我當一個類應該分解成兩個或多個類別。我可以告訴你，我的經驗法則是，當我看到不止一個廣泛的責任時，我就重構其中的一項責任。但這更像是一種「最佳做法」，我想更準確地說明這一點。

我發現的最接近的是單一責任原則。 「單一責任原則規定，每個對象都應該承擔一項責任。」但是什麼是責任？如何確切地定義？

鮑勃馬丁說這是「改變的理由」。舉一個具體的例子，假設你有一個應用程序，它接受一個輸入，處理它並創建一個輸出。這將導致三個方面的變化 - 輸入（可能來自字符串或XML）。處理器可以改變它的規則。輸出可能會改變：它可能是字符串或XML或數據庫。所以它會給你三個頂級的課程。

再次，不尋找辯論或最佳做法，但如果有一個堅實的分解原則。或者，也許，一個堅實的構圖原則將是一個更好的陳述方式。

的動機在我身後分解成分 - 我發現高度由應用程序是更加靈活和易於使用。

另一個原因分解，使我作爲一個開發者，通過看類，可以更好地瞭解整個應用程序。爲了對班級有一個清晰的理解，我認爲班級有一個明確的目的。雖然這與類命名有關，但我認爲如果一個類有這樣一個目的，那將是最容易理解的，因此是分解的一個很好的基礎。

向上面應用此例子中，這將是明顯的在哪裏看，如果我需要做的輸入，處理和輸出維護，我開始在明顯的類作爲每個人都有一個明顯的目的。 （但我只是想大聲這裏，試圖澄清自己。）

所以，問題是：什麼是分解的好處，什麼指示類應該被分解？

Answer 1

關於單一職責，一個很好的例子就是應用程序的數據層。在我的大多數小應用程序中，我有一個存儲庫可處理來自單個數據庫的所有數據的讀取/寫入。在大多數情況下，它負責處理一個對象類型，但在一些情況下，我有查詢返回複雜的對象或簡單的字符串。

有些過分熱心的開發人員會走這麼遠的說，我不應該有對付我的域對象，以及那些像返回字符串和整數簡單數據的方法。在這樣的情況下，你必須用最好的判斷力來確定你的課程什麼時候沒有重點或臃腫，並相應地進行重構。