SRP 和很多课程
我正在重构几个月前编写的一些代码，现在我发现自己创建了很多小型类（很少的属性、2-4 个方法、1-2 个事件）。
这是应该的样子吗？或者这也有点代码味道？
我的意思是，如果一个类确实需要很多方法来履行它的职责，我想它就应该是这样的，但我不太确定很多小类是不是特别好的做法？
I'm refactoring some code I wrote a few months ago and now I find myself creating a lot of smallish classes (few properties, 2-4 methods, 1-2 events).
Is this how it's supposed to be? Or is this also a bit of a code smell?
I mean if a class does need a lot of methods to carry out it's responsibility, I guess that's how it's gotta be, but I'm not so sure that a lot small classes is particularly good practice either?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
许多小类听起来很好:)
特别是如果您让每个类实现一个接口并让不同的协作者通过这些接口进行通信而不是直接相互通信，那么您应该能够实现所谓的Supple Design< /strong> （领域驱动设计中的术语）有很多松散的内容耦合。
如果您可以将其归结为重要操作具有与输入相同类型的输出，您将实现埃文斯所说的操作闭包，我发现这是一种特别强大的设计技术。
当您应用 SRP 时，往往会发生的情况是，尽管所有类一开始都很小，但您不断重构，有时突然的洞察力会澄清一些特定的类可能比以前假设的要丰富得多。
去做吧，但要永远重构:)
Lots of small classes sounds just fine :)
Particularly if you let each class implement an interface and have the different collaborators communicate through those interfaces instead of directly with each other, you should be able to achieve a so-called Supple Design (a term from Domain-Driven Design) with lots of loose coupling.
If you can boil it down so that important operations have the same type of output as input, you will achieve what Evans call Closure of Operations, which I've found to be a particularly strong design technique.
What tend to happen when you apply the SRP is that although all classes start out small, you constantly refactor, and from time to time it happens that a rush of insight clarifies that a few particular classes could be a lot richer than previously assumed.
Do it, but keep refactoring forever :)
srp 的宗旨是提供许多职责明确的小班课程。所以，是的，对于 SRP 倡导者来说，这就是事情“应该是”的方式。但是您会发现系统中的类数量呈爆炸式增长，并且开始变得非常难以记住或直观地知道事情实际上在哪里完成，不是吗？事实上，你暴露了一种新的代码味道，这是随着 srp 而来的（通常是不必要的）复杂性的增加。我在此处写了一篇关于它的条目。看看你是否同意。
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.
我认为你必须找到中间道路。太多的课程有时是多余的。从我的角度来看，我尝试在较小的层面上分离关注点，如果事情进展顺利，则重构出更粗粒度的：
我发现这种（爆炸式）方法更自然，因为从一开始就创建了大量的类和包。但这也取决于...：如果我一开始就可以看到更大的组件，我已经创建了专用的包结构。
也许有关您的代码的更多详细信息可以提供更具体的帮助:)
I think you have to find the middle way. Too many classes are sometimes overkill. From my side I try to separate concerns on a smaller level and if things are getting then refactor out more coarse grained:
I found this (explosion) approach more natural as creating lots of classes and packages from start on. But this also depends...: If I can already see bigger components at the beginning I already create dedicated package structures.
Maybe some more details about your code to offer some more concrete help :)