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

Question

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

我有几个类（棋盘、走法生成器和 PGN 解析器），总共大约 1,200 行代码。移动生成器和解析器都与棋盘类紧密耦合，很容易将所有三个类简单地组合成一个大型“厨房水槽”类。

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

除了明显的可读性/可维护性问题之外，与大量较小的简单类相比，拥有较少数量的大型复杂类有什么缺点？

干杯！ 卑微的程序员 ,,,^..^,,,

Answer 1

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

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

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

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

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

我有几个类（棋盘、走法生成器和 PGN 解析器），总共大约 1,200 行代码。移动生成器和解析器都与棋盘类紧密耦合，很容易将所有三个类简单地组合成一个大型“厨房水槽”类。

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