什麼時候分裂一個類

那麼我有下面這個叫做「架構」的類，這個類有很多方法（我認爲大約有50個），問題是代碼可讀性，這些方法中的很多似乎屬於不同的類。什麼時候分裂一個類

因此，我創建了一個「ArchitectureProcessor」類，其中包含這些方法及其「構造」的組合。 這是一個很好的做法嗎？

我的意思是我不想在一個班級上有50個方法，它看起來很亂，所以我儘量把每個班級拆分得最多，我經常發現這個問題。

2013-06-30 ffenix

有很多東西是「良好做法」，可以幫助您決定何時分開課程。您可以從單一責任原則開始（請參閱本文[Stack Overflow Question]（http://stackoverflow.com/questions/7542051/learning-single-responsibility-principle-with-c-sharp）） –

「Architecture」doesn'不知道班級是做什麼*。按功能分解，應該有所幫助。你能提供一些代碼嗎？ –

你的50方法類可能做得太多了。

正如已經在評論中提到的那樣，您應該嘗試遵循單一責任原則，這意味着一個類只應該有一個責任。如果它有不止一個責任，可以嘗試根據他們不同的責任將班級分成多個班級。

單一責任原則是杜撰SOLID較大基團的原理的一部分：

單一職責原則
打開/封閉原則
里氏替換原則
接口分離原則
依賴反轉原理

所有這些原則將幫助您遠離類似的代碼，並且是面向對象編程的良好指南。

來源

2013-06-30 01:11:50

現在是時候分裂一個類，只要它有多個責任。

你的閱讀課程開始寫作，分裂。
你的邏輯類開始更新用戶界面，拆分。

來源

2013-06-30 01:10:41 Jeremy1026

在我看來，這不是關於類的大小，而是關於你在其中分組的功能。從理論上講，任何規模的班級都可以成爲適當的班級。

來源

2013-06-30 01:11:57 aw04

不要爲了分裂而拆分。您只能使接口的尷尬 - 而不是architecture.Foo()你必須寫architecture.Process.Foo() - 這不是自然的東西的Process標識有...

如果你有太多的方法，也許你的類是試圖表示整個層次本身？假設Architecture是關於建築物，也許它也試圖代表建築物的樓層，所以你有像RoomCountInFloor(int floorNumber)的方法。在這種情況下，你應該有一個Floor類，Architecture應該包含一個樓層集合，所以你可以寫architecture.Floors[5].RoomCount - 比architecture.Process.RoomCountInFloor(5)好很多，對嗎？

另一種可能性是您使用的服務方法過多 - 在這種情況下，您可能希望將這些服務方法放入服務類中。在我做過一次的Java項目中，我必須使用許多服務方法來管理我的某個類正在使用的所有臨時文件。我沒有將這些服務方法添加到該類中，而是創建了一個TempFileManager類來完成此操作。這種分裂迫使我添加一些更多的方法（封裝和所有），但它的組織方式更加複雜，現在如果我需要在另一個項目中使用類似的臨時文件管理，我可以簡單地複製該類。

也有可能你需要50個方法來直接處理任何Architecture表示，但是在一個大文件中使用這些方法太雜亂。在這種情況下，您應該考慮使用C#'s partial class feature。

來源

2013-06-30 01:33:10

什麼時候分裂一個類

回答

相關問題