我正在重构几个月前编写的一些代码，现在我发现自己创建了很多小类（很少的属性、2-4 个方法、1-2 个事件）。
这是应该的吗？或者这也有点代码味道？
我的意思是，如果一个类确实需要很多方法来履行它的职责，我想这就是它的样子，但我不太确定很多小类是不是特别好的实践？
问问题
1272 次
3 回答
4
很多小班听起来不错:)
特别是如果你让每个类实现一个接口并且让不同的协作者通过这些接口而不是直接相互通信，你应该能够实现一个所谓的Supple Design（来自领域驱动设计的一个术语）有很多松散的耦合。
如果您可以将其归结为重要操作具有与输入相同类型的输出，您将实现 Evans 所说的操作闭包，我发现这是一种特别强大的设计技术。
当您应用 SRP 时往往会发生的情况是，尽管所有类一开始都很小，但您会不断地重构，并且有时会突然发现一些特定的类可能比以前假设的要丰富得多。
这样做，但要永远重构:)
于 2009-12-26T18:54:33.867 回答
1
Lots of small classes with focused responsibilties are what srp is all about. So, yes, this is the way things are "supposed to be" as far as srp advocates are concerned. But you're seeing an explosion of the number of classes in your system and it's beginning to become very difficult to remember or to intuitively know where things are actually done, isn't it? You are, indeed, exposing a new code smell, which is the (usually unnecessary) increase of complexity that comes aong with srp. I wrote an entry about it here. See if you might agree.
于 2009-12-26T19:39:08.003 回答
1
我认为你必须找到中间道路。太多的类有时是矫枉过正的。从我的角度来看，我尝试在较小的级别上分离关注点，如果事情变得更粗粒度，则重构：
首先通过提取方法编写单独的关注点。如果你能看到一组关于数据的方法（实例+静态字段）来形成一个专门的责任'提取类'。一段时间后，如果您可以在包中看到不同的类分组，请执行“提取包”。
我发现这种（爆炸）方法更自然，因为从一开始就创建了许多类和包。但这也取决于...：如果我一开始就可以看到更大的组件，我已经创建了专用的包结构。
也许有关您的代码的更多详细信息可以提供更具体的帮助:)
于 2009-12-27T14:30:46.513 回答