好吧，我有一个名为“Architecture”的类，这个类有很多方法（我认为大约有 50 个）问题是代码可读性，其中许多方法似乎属于不同的类。
所以我创建了一个“ArchitectureProcessor”类，其中包括这些方法及其“Architecture”的组合。这是一个好习惯吗？
我的意思是我不想在一个类上有 50 个方法，它看起来很乱，所以我尽量拆分每个类，我经常发现这个问题。
问问题
1812 次
4 回答
9
您的 50 个方法类可能做得太多了。
正如评论中已经提到的，您应该尝试遵循单一职责原则，这意味着一个类应该只有一个职责。如果它有多个职责，请尝试根据不同的职责将类分解为多个类。
单一责任原则是创造出SOLID的一大组原则的一部分：
- 单一职责原则
- 开闭原则
- 里氏替换原则
- 接口隔离原则
- 依赖倒置原则
所有这些原则将帮助您远离类似的代码，并且是面向对象编程的良好指南。
于 2013-06-30T01:11:50.453 回答
2
在我看来，这与班级的规模无关，而与您在其中分组的功能有关。理论上，任何大小的类仍然可以是适当的类。
于 2013-06-30T01:11:57.767 回答
2
不要为了分裂而分裂。你只是让界面变得尴尬——而不是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# 的部分类功能。
于 2013-06-30T01:33:10.737 回答
0
是时候拆分一个类，因为它有多个职责。
- 你的阅读课开始写作，分裂。
- 你的逻辑类开始更新用户界面，拆分。
于 2013-06-30T01:10:41.733 回答