相当一个学术问题 - 我已经说过我在WCF服务中编写的一个类很长(~3000行),它应该分解成更小的类.
服务的范围随着时间的推移而增长,并且包含的方法包含许多类似的函数,因此我到目前为止还没有创建多个较小的类,所以我没有这样做的问题(除了它需要这样做的时间!) ,但它让我思考 - 使用单个大类而不是多个较小的类是否有显着的性能开销？如果是这样,为什么？
Bot*_*000 19
它不会有任何明显的区别.在考虑这种极端的微优化之前,你应该考虑可维护性,这对于大约3000LT的类是非常危险的.
首先编写代码,使其正确且可维护.只有当您真正遇到性能问题时,才应首先对应用程序进行概要分析,然后再做出有关优化的决策.通常,性能瓶颈会在其他地方找到(缺乏并行化,糟糕的算法等).
不,有一个大班不应该影响表现.将较大的类拆分为较小的类甚至可能会降低性能,因为您将有更多的重定向.但是,几乎在所有情况下,影响都可以忽略不计.
将类拆分为较小的部分的目的不是为了提高性能,而是为了更容易阅读,修改和维护代码.但仅此一点就足以说明这一点.
在决定在单个源文件中添加一些设计良好的类时,性能考虑因素是您最后的担忧.多想想看:
我可以继续,但大型单一源文件的心态似乎可以追溯到VB/Procedureal编程时代.如今,如果一个方法的圈复杂度超过15并且一个类的行数超过几百行,我就会开始担心.
通常我发现如果我重构这些10k行代码中的一个庞然大物,那么新类代码行的总和最终将达到原始代码的40%(如果不是更少).更多的类和分解(在合理范围内)会导致更少的代码.起初违反直觉,但确实有效.