这是一个学术问题 - 我已经说过我在WCF服务中编写的一个类很长（~3000行），应该分解成更小的类。
服务的范围随着时间的推移而增长，并且包含的方法包含许多类似的功能，因此我到目前为止还没有创建多个较小的类，所以我这样做没有问题（除了它需要做的时间之外）所以！），但它让我思考 - 使用单个大型类而不是多个较小的类会有显着的性能开销吗？如果是这样，为什么？
答案 0 :(得分：19)
它不会有任何明显的区别。在考虑这种极端的微优化之前，你应该考虑可维护性，这对于大约3000LT的类是非常危险的。
首先编写代码，使其正确且可维护。只有当您遇到性能问题时，才应首先对应用程序进行概要分析，然后再做出有关优化的决策。通常，性能瓶颈会在其他地方找到（缺乏并行化，糟糕的算法等）。
答案 1 :(得分：9)
不，拥有一个大班不应该影响表现。将大型类拆分为较小的类甚至可以降低性能，因为您将有更多的重定向。但是，几乎在所有情况下，影响都可以忽略不计。
将类拆分为较小的部分的目的不是为了提高性能，而是为了更容易阅读，修改和维护代码。但仅此一点就足以说明这一点。
答案 2 :(得分：7)
在决定在单个源文件中添加一些设计良好的类时，性能考虑因素是您最后的担忧。多想想看：
我可以继续，但大型单一源文件的心态似乎可以追溯到VB / Procedureal编程时代。如今，如果一个方法的圈复杂度超过15且一个类的行数超过几百行，我就会开始担心。
通常我发现如果我重构这些10k行代码中的一个庞然大物，那么新类代码行的总和最终会达到原始代码的40％（如果不是更少）。更多的类和分解（在合理范围内）会导致更少的代码。起初违反直觉，但确实有效。
答案 3 :(得分：3)
真正的问题不是性能开销。开销是可维护性和重用。您可能很难实现面向对象设计的SOLID原则，其中一些原则意味着更小的类更好。特别是，我会看一下单一责任原则，开放/封闭原则和利斯科夫替代原则，并且......实际上，考虑到这一点，它们都意味着更小的类更好，尽管是间接的。
这个东西不容易“搞定”。如果您使用OO语言进行编程，那么在看一下SOLID时它会突然变得非常有意义。但是在这些灯泡出现之前，它看起来有点模糊。
更简单的说明，拥有多个类，每个类有一个文件，每个类都有明确的名称来描述行为，每个类只有一个作业，从纯粹的理智角度来看，要比较长页面3000行。
然后考虑你的3,000行的一部分是否可能在你的程序的另一部分中有用...将该功能放在一个专用的类中是封装它以便重用的一种很好的方法。
从本质上讲，正如我写的那样，我发现我只是在戏弄SOLID的各个方面。你可能最好阅读straight from the horses mouth on this。
答案 4 :(得分：1)
我不会说存在性能问题，而是维护可读性问题。修改每个执行其目的的类比使用单个怪异类更容易。那太荒谬了。你这样做会破坏所有的OOP原则。
因此我到目前为止还没有创建多个小班，所以我没有 这样做的问题
正是这种情况我已经多次警告SO了......人们害怕过早优化，但他们并不害怕编写一个错误的代码，并且有一个想法，“我会在以后修复它成为一个问题“。让我告诉你一些事情 - 无论性能如何影响，3000 + LOC类都已成为问题。
答案 5 :(得分：1)
这取决于如何使用类以及实例化的频率。当类被实例化一次时，例如合同服务类，比典型的性能开销并不重要。
当经常对类进行实例化时，它会降低性能。
但在这种情况下，不要考虑性能，考虑设计。更好地考虑支持，进一步开发和可测试性。 3K LOC的类别很大，通常是反模式的书籍。这些类导致代码重复和错误，进一步的开发将是痛苦的，并导致已经修复的错误一次又一次出现，代码是脆弱的。
所以上课肯定应该重构。