这是一个相当学术的问题——我已经注意到我在 WCF 服务中编写的一个类很长（大约 3000 行），它应该被分解成更小的类。
服务的范围随着时间的推移而扩大，并且包含许多类似功能的方法，因此我直到现在还没有创建多个较小的类，所以我这样做没有问题（除了这样做需要时间！） ，但它让我思考 - 使用单个大类而不是多个小类是否存在显着的性能开销？如果是这样，为什么？
user1330152
问问题
2740 次
6 回答
19
它不会产生任何明显的差异。在考虑这种极端的微优化之前，您应该考虑可维护性，这对于大约 3000 LOC 的类来说是相当危险的。
首先编写代码，使其正确且可维护。只有当你真的遇到性能问题时，你才应该首先分析你的应用程序，然后再做出任何关于优化的决定。通常会在其他地方发现性能瓶颈（缺乏并行化、糟糕的算法等）。
于 2012-06-13T11:26:19.743 回答
9
不，有一个大类不应该影响性能。将大类拆分为小类甚至会降低性能，因为您将有更多的重定向。但是，几乎在所有情况下，影响都可以忽略不计。
将一个类拆分成更小的部分的目的不是为了提高性能，而是为了更容易阅读、修改和维护代码。但仅此一项就足够了。
于 2012-06-13T11:27:24.887 回答
7
当决定在单个源文件上添加一些设计良好的类时，性能考虑是您最后的担忧。多想想：
- 可维护性......很难在这么多代码中进行点修复。
- 可读性...如果您必须像恶魔一样上下翻页才能到达任何地方，那么它是不可读的。
- 可重用性...没有分解使事情难以重用。
- 凝聚力...如果你在一个班级里做的事情太多，它可能无论如何都没有凝聚力。
- 可测试性...祝你好运，单元测试 3,000 LoC 一堆意大利面条代码到任何合理的覆盖范围。
我可以继续，但大型单一源文件的心态似乎可以追溯到 VB/Procedureal 编程时代。现在，如果一个方法的圈复杂度超过 15 并且一个类中有超过几百行，我开始害怕。
通常我发现，如果我重构这些 10k 行代码庞然大物之一，新类的代码行总和最终将是原始代码的 40%，如果不是更少的话。更多的类和分解（在合理范围内）导致更少的代码。起初违反直觉，但它确实有效。
于 2012-06-13T11:30:07.027 回答
3
真正的问题不是性能开销。开销在于可维护性和重用性。您可能很难理解面向对象设计的SOLID原则，其中一些意味着较小的类更好。特别是，我会看看单一责任原则、开放/封闭原则和 Liskov 替换原则，而且……实际上，想想看，它们几乎都意味着较小的类更好，尽管是间接的。
这东西不容易“得到”。如果您一直在使用 OO 语言进行编程，那么您看看 SOLID，它突然变得非常有意义。但在那些灯泡亮起之前，它似乎有点晦涩难懂。
在一个更简单的说明中，有几个类，每个类一个文件，每个类都有一个合理的命名来描述行为，每个类都有一个工作，从纯粹的理智的角度来看，必须比 3,000 长页更容易管理线。
然后考虑您的 3,000 行类中的一个部分是否可能在您程序的另一部分中有用......将该功能放在专用类中是封装它以供重用的极好方法。
本质上，在我写作的时候，我发现我只是在梳理 SOLID 的各个方面。你可能最好直接从马嘴里读到这一点。
于 2012-06-13T11:33:39.887 回答
1
我不会说存在性能问题，而是维护可读性问题。修改更多每个执行其目的的类比使用单个怪物类要容易得多。这太荒谬了。你这样做违反了所有 OOP 原则。
因此我直到现在还没有创建多个较小的类所以我这样做没有问题
正是这种情况，我已经在 SO 多次警告过......人们害怕过早的优化，但他们不害怕写一个糟糕的代码，比如“我会在以后出现问题时修复它”。让我告诉你一些事情 - 3000+ LOC 类已经是一个问题，无论性能影响（如果有的话）。
于 2012-06-13T11:27:43.547 回答
1
这取决于如何使用类以及实例化的频率。当类被实例化一次时，例如合同服务类，典型的性能开销并不显着。
当类经常被实例化时，它可能会降低性能。
但在这种情况下，不要考虑性能，而要考虑设计。最好考虑支持以及进一步的开发和可测试性。3K LOC 类是巨大的，通常是反模式书籍。这样的类导致代码重复和错误，进一步的开发将是痛苦的，导致已经修复的错误一次又一次出现，代码很脆弱。
所以类绝对应该重构。
于 2012-06-13T11:31:57.777 回答