c＃中大类大小的性能开销

Question

相当一个学术问题 - 我已经说过我在WCF服务中编写的一个类很长（~3000行），它应该分解成更小的类。

服务的范围随着时间的推移而增长，并且包含的​​方法包含许多类似的函数，因此我到目前为止还没有创建多个较小的类，所以我这样做没有问题（除了这样做的时间！） ，但它让我思考 - 使用单个大类而不是多个较小的类是否有显着的性能开销？ 如果是这样，为什么？

Answer 1

它不会有任何明显的区别。 在考虑这种极端的微优化之前，你应该考虑可维护性，这对于大约3000LT的类是非常危险的。

首先编写代码，使其正确且可维护。 只有当您遇到性能问题时，才应首先对应用程序进行概要分析，然后再做出有关优化的决策。 通常，性能瓶颈会在其他地方找到（缺乏并行化，糟糕的算法等）。

Answer 2

不，有一个大班不应该影响表现。 将较大的类拆分为较小的类甚至可能会降低性能，因为您将有更多的重定向。 但是，几乎在所有情况下，影响都可以忽略不计。

将类拆分为较小的部分的目的不是为了提高性能，而是为了更容易阅读，修改和维护代码。 但仅此一点就足以说明这一点。

Answer 3

在决定在单个源文件中添加一些设计良好的类时，性能考虑因素是您最后的担忧。 多想想看：

• 可维护性......很难在如此多的代码中修复点。
• 可读性......如果你必须像一个恶魔一样向上和向下翻页以获得任何地方，那就不可读了。
• 可重用性......没有分解会使事情难以重用。
• 凝聚力......如果你在一个班级里做太多事情，那么它可能没有任何凝聚力。
• 可测试性...祝你好运单位测试3,000 LoC意大利面条代码到任何合理的覆盖范围。

我可以继续，但大型单一源文件的心态似乎可以追溯到VB / Procedureal编程时代。 如今，如果一个方法的圈复杂度超过15并且一个类的行数超过几百行，我就会开始担心。

通常我发现如果我重构这些10k行代码中的一个庞然大物，那么新类代码行的总和最终将达到原始代码的40％（如果不是更少）。 更多的类和分解（在合理范围内）会导致更少的代码。 起初违反直觉，但确实有效。

Answer 4

真正的问题不是性能开销。 开销是可维护性和重用。 您可能很难掌握面向对象设计的SOLID原则，其中一些原则意味着较小的类更好。 特别是，我会看一下“单一责任原则”，“开放/封闭原则”和“利斯科夫替代原则”......实际上，考虑到这一点，它们几乎意味着较小的类别更好，尽管是间接的。

这个东西不容易“搞定”。 如果您使用OO语言进行编程，那么在看一下SOLID时它会突然变得非常有意义。 但是在这些灯泡出现之前，它看起来有点模糊。

更简单的说明是，拥有多个类，每个类有一个文件，每个类都用于描述行为，每个类只有一个作业，从纯粹的理智角度来看，必须比3000页的长页更容易管理。线。

然后考虑3000行类的一部分是否可能在程序的另一部分中有用...将该功能放在专用类中是封装它以便重用的一种很好的方法。

从本质上讲，正如我所写，我发现我只是在戏弄SOLID的各个方面。 你可能最好直接从马口读出来 。

Answer 5

我不会说存在性能问题，而是维护可读性问题。 修改每个执行其目的的类比使用单个怪异类更容易。 那太荒谬了。 你这样做会违反所有OOP原则。

因此我到目前为止还没有创建多个较小的类，所以我没有问题

确切地说，我已经多次警告SO了......人们害怕过早优化，但是他们并不害怕编写一个错误的代码，并且有一个想法，“我会在以后成为一个问题时修复它”。 让我告诉你一些事情 - 3000+ LOC类已经是一个问题，无论性能如何影响，如果有的话。

Answer 6

这取决于如何使用类以及实例化的频率。 当类被实例化一次时，例如合同服务类，比典型的性能开销并不重要。

当经常实例化类时，它会降低性能。

但在这种情况下，不要考虑性能，考虑它的设计。 最好考虑支持，进一步开发和可测试性。 3K LOC的类别很大，通常是反模式的书籍。 这些类导致代码重复和错误，进一步的开发将是痛苦的，并导致已经修复的错误一次又一次出现，代码是脆弱的。

所以上课肯定应该重构。