我有一個關於我的代碼結構以及如何保持類簡單的問題。我正在努力簡化C＃項目的服務層。大部分代碼沒有考慮到OOP實踐，並且有200多行的方法很少有類。我已經開始提取出更小的方法，但對如何做到這一點有一個快速查詢。服務層和簡化類
作爲一個例子，我有一個方法來檢索特定於客戶的文件目錄，然後檢查它們是否存在，如果它們不存在則創建它們，最後返回一個帶有這些目錄列表的對象。我想堅持不使用私有方法的原則，並將其提取到新類中，儘管傳統的我會創建私有方法來檢查目錄是否存在，另一個用於創建它們，第三個用於檢索文件夾名稱並返回對象和公共方法使用單個方法按順序調用所有這些方法。
我應該爲這些私有方法中的每一個創建新的類嗎？如果是的話，他們是否都需要一個接口？或者讓他們全部公開並從別處打電話給他們？
在此先感謝！
簡答：你不應該做那些事情。
如果你想從面向對象的角度來處理這個問題，那麼暫時忘記這些方法正在做什麼。想想代碼約爲。您只提到「客戶」作爲可能的「業務」相關的事情。試着想出其他商業相關的東西。這些文件是什麼？報告？ ActivityLogs？消息？ CreditReports :)？
問題是，面向對象並不是僅僅在不同類中有方法。類別和方法必須具有一定的商業意義。如果他們沒有任何意義，那麼沒有真正的理由讓他們擺在首位！
由此可見，「StorageManager」，「StorageUtil」等類似的東西不應該存在，因爲它根本沒有任何商業意義。
因此，從找出應用程序約爲（事情）開始，然後您可以將某些職責移動到適當的位置。
謝謝你的回覆。這使我從不同的角度看待該節目。我可以將商業邏輯應用於此，因爲我正在處理訂單文件。所以如果我有一個與處理訂單文件相關的類，那麼使用私有方法還是創建與訂單文件處理的一部分有關的新類會更好。最後，那些也需要接口.....我假定在庫和服務層中的所有東西都應該有接口。 – Boggot
我懷疑這個問題將被關閉。無論如何，下面是我如何處理它：在具有專用文件存儲的應用程序中，我傾向於創建一個'StorageManager'類，它負責爲我希望使用的每個文件路徑提供服務。它的設置方式是，如果返回的文件路徑不存在，則自動創建所有返回的文件路徑。如果您有多個存儲（使用不同的文件夾結構），我傾向於從'StorageManager'繼承並覆蓋路徑生成。不知道這種方式是否客觀是最好的方式，但我覺得這是一種乾淨的方法。 – Flater