使用部分類來管理代碼，很好的解決方案？

Question

書籍通常會說，如果課程變得太大而無法管理，請重新考慮實施，因爲設計需要更正的可能性很大，因爲課程尚未得到適當的定義。

但是在類確實很大的情況下，例如當一個類被擴展來實現一個控件的功能時（例如Canvas），並且有很多不同的東西，比如命中測試，繪圖，管理繪製項目等。在這種情況下使用部分類來分離更大容器（例如自定義控件）的「不同」事物是否是一個很好的解決方案？其次，作爲更廣泛和更廣泛的解決方案，在轉向部分類之前應該考慮什麼？

Answer 1

是的，如果該類是自然大，使用部分類可以幫助您管理源代碼。我之前使用過這個功能，將單個生產文件的測試拆分爲多個源測試文件。同樣，當將LINQ重新實現爲對象時，我使用了部分類來將每個LINQ「操作符」放在它自己的文件中 - 儘管它們都貢獻給一個名爲Enumerable的類。

部分類不是一個很好的選擇，以良好的設計雖然 - 當你可以讓您的實際類較小，這是值得這樣做。如果你發現你有一個你想要分解的類，部分類可以幫助你將這個大類重構爲兩個更小的類 - 你可以將類分成兩部分，而不必改變它的功能，然後執行真正的分裂在一個更小的步驟。

Answer 2

這是一種幻覺。它只是將課程分成兩個物理文件。您仍然與Single Responsibility Principle，低cohesion等發生衝突。

部分類主要用於自動代碼生成工具。您可以編輯分部類，而不用擔心在工具重新生成另一部分時它會被覆蓋。

構圖是避免大類的幾種方法之一。 A類有一個B類實例，併爲其部分功能進行委託。在很多情況下，dependency injection可用於解耦這兩個類（A類通過B類實現的接口，通常在A的構造函數中）。

Answer 3

命中測試似乎不是一個畫布任務，可以很容易地被委派到另一個類實現像

public interface IHitTester 
{ 
    List<Shape> GetHits(List<Shape> allShapes, Point point); 
} 

它增強了可測試性的接口，可以讓你用不同的命中測試的實施進行實驗（戰略格局）並增強您的代碼的可讀性。

如果您重新考慮您的畫布類，我相信您可以用相同的方式將其他任務提取到其他類。