C# 中“厨房水槽”类的优缺点

在

单个 C# 类中包含大量变量、属性和/或方法是否会造成任何明显的性能损失？

拥有更多变量会导致实例具有更高的内存使用率和可能更长的构建时间 - 如果不一定在每种情况下都需要变量，这可能会产生损失。

话虽如此，主要缺点更多是在可靠性、可维护性、可测试性方面。

我理解并赞赏让每个类专注于单个任务并干净地封装其内部设计的概念，但由于使用 .NET 是一项不可协商的要求，我也愿意牺牲"设计的纯粹性"来换取性能。

.NET 与制作糟糕的代码无关 - 您可以在同一个项目中拥有良好的设计和 .NET，事实上，这很容易实现。

我有几个类（棋盘、移动生成器和 PGN 解析器），总共大约有 1，200 行代码。移动生成器和解析器都与板类紧密耦合，并且有一种强烈的诱惑力，即简单地将所有三个类组合成一个大的"厨房水槽"类。

我会考虑尝试找到重构它的动机，并将其解耦为更多、更小的类。 这可能在各个方面都有帮助，包括性能（如果您认为有必要），因为在干净、经过深思熟虑的设计中修复性能问题通常比在紧密耦合的大型代码库中查找或修复性能问题更简单。 较小的类更容易分析和测量，这反过来又允许发现和纠正真正的性能问题（如果有的话），比处理大量代码要简单得多。