SRP和很多類

Question

我重構了幾個月前我寫的一些代碼，現在我發現自己創建了很多小類（很少屬性，2-4個方法，1-2個事件）。

這是它應該如何？或者這也是一種代碼味道？

我的意思是如果一個班級確實需要很多方法來執行它的責任，我想這就是它的要求，但我不確定很多小班是特別好的做法嗎？

Answer 1

很多小班的聲音就好了:)

特別是如果你讓每個類實現一個接口，並有不同的合作者，通過這些接口，而不是直接相互通信，你應該能夠實現這樣稱爲柔軟設計（從Domain-Driven Design一詞）與大量的鬆耦合。

如果可以熬下來，這樣重要的操作具有相同類型的輸入輸出，你會達到什麼叫埃文斯封運營的，我已經發現特別強的設計技術。

當你應用SRP時會發生什麼事情是，雖然所有的課程都是從小規模開始的，但你經常會重構，而且時不時發生的事情是，有一陣子的見解澄清了一些特定的課程可能比先前假設。

做吧，但要永遠重構:)

Answer 2

很多小班與集中responsibilties是什麼SRP是怎麼一回事。所以，是的，就srp提倡者而言，事情「應該是這樣」。但是，你看到系統中類的數量激增，並且它開始變得很難記住，或者直覺地知道事情實際上在哪裏完成，不是嗎？事實上，你確實暴露了一種新的代碼異味，這是隨着srp而來的複雜性（通常是不必要的）增加。我寫了一個關於它的條目here。看看你是否同意。

Answer 3

我認爲你必須找到中間道路。太多的課程有時候過於誇張。從我的角度來看，我嘗試在較小的級別上分離問題，如果事情正在重構出更粗糙的粒度：

首先通過提取方法編寫單獨的問題。如果你能看到一組關於數據的方法（實例+靜態字段）來形成專門負責的'提取類'。過了一段時間，如果你可以看到一個包內的不同類的組合，「提取包」。

我發現這個（爆炸）方法更自然，因爲從開始創建大量的類和包。但是這也取決於......如果我已經可以在開始時看到更大的組件，我已經創建了專用的包結構。

也許關於你的代碼的更多細節提供一些更具體的幫助:)