何时分班

本文关键字：何时 | 更新日期: 2023-09-27 18:20:21

我有一个名为"Architecture"的类，这个类有很多方法（我认为大约有50个），问题是代码的可读性，其中许多方法似乎属于不同的类。

因此，我创建了一个"ArchitectureProcessor"类，其中包括这些方法及其"Architecture"的组合这是个好做法吗

我的意思是，我不想在一个类上有50个方法，它看起来很乱，所以我尽量拆分每个类，我经常发现这个问题。

何时分班

您的50方法类可能做得太多了。

正如已经在评论中提到的，您应该尝试遵循单一责任原则，这意味着一个类应该只有一个责任。如果它有多个职责，请尝试根据不同的职责将类分解为多个类。

单一责任原则是一组更大的原则的一部分，创造了SOLID：

  • 单一责任原则
  • 打开/关闭原理
  • 利斯科夫替代原理
  • 接口隔离原则
  • 依赖反转原理

所有这些原则都将帮助您摆脱类似的代码，并且是面向对象编程的良好指南。

在我看来，这与类的大小无关，而是与你在其中分组的功能有关。理论上，任何大小的类都可以是一个合适的类。

不要为了拆分而拆分。你只会让接口变得尴尬——你必须写architecture.Process.Foo()而不是architecture.Foo()——在那里填充Process标识符是不自然的。。。

如果你有太多的方法，也许你的类试图自己表示整个层次结构？假设Architecture是关于建筑物的，也许它也试图表示建筑物的楼层，所以可以使用类似RoomCountInFloor(int floorNumber)的方法。在这种情况下，您应该有一个Floor类，而Architecture应该包含楼层的集合，这样您就可以编写architecture.Floors[5].RoomCount——比architecture.Process.RoomCountInFloor(5)好得多，对吧？

另一种可能是您使用了太多的服务方法，在这种情况下，您可能希望将这些服务方法放入服务类中。在我曾经做过的一个Java项目中，我不得不使用许多服务方法来管理我的一个类正在使用的所有临时文件。我没有将这些服务方法添加到该类中，而是创建了一个TempFileManager类来执行此操作。这种拆分迫使我添加了更多的方法（封装等等），但它的组织性更强，现在如果我在另一个项目中需要类似的临时文件管理，我可以简单地复制该类。

也有可能您确实需要50个方法来直接处理Architecture表示的任何内容，但将所有这些方法放在一个大文件中太麻烦了。在这种情况下，您应该考虑使用C#的分部类特性。

一旦一个类有多个责任，就应该立即拆分它。

  • 你的阅读课开始写作，分开
  • 您的逻辑类开始更新用户界面，拆分
相关文章：