C#中"厨房水槽"课程的优缺点

Hum*_*mer 0 c#

在单个C#类中拥有大量变量,属性和/或方法是否会有任何明显的性能损失?

我有几个类(一个棋盘,移动生成器和一个PGN解析器),总共约1,200行代码.移动生成器和解析器都非常紧密地耦合到板类,并且很有可能简单地将所有三个类组合成一个大的"厨房接收器"类.

我理解并赞扬将每个课程都集中在一个任务上并干净地封装其内部设计的概念,但由于使用.NET是一个不可妥协的要求,我也愿意牺牲"纯粹的设计"来换取性能

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

干杯! 谦虚的程序员,,, ^ .. ^ ,,,

Ree*_*sey 14

在单个C#类中拥有大量变量,属性和/或方法是否会有任何明显的性能损失?

拥有更多变量会导致实例具有更高的内存使用量和可能更长的构造时间 - 如果在每种情况下都不一定需要变量,则可能会受到惩罚.

话虽如此,主要缺点在于可靠性,可维护性,可测试性.

我理解并赞扬将每个课程都集中在一个任务上并干净地封装其内部设计的概念,但由于使用.NET是一个不可妥协的要求,我也愿意牺牲"纯粹的设计"来换取性能

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

我有几个类(一个棋盘,移动生成器和一个PGN解析器),总共约1,200行代码.移动生成器和解析器都非常紧密地耦合到板类,并且很有可能简单地将所有三个类组合成一个大的"厨房接收器"类.

我会考虑尝试找到重构它的动机并将其分解为更小的类.这可能在各方面都有所帮助,包括性能(如果您认为有必要),因为在一个干净,经过深思熟虑的设计中解决性能问题通常比在紧急情况下找到或修复性能问题更简单耦合,大型代码库.较小的类更容易分析和测量,这反过来允许比从大量代码处理时更简单地发现和纠正真正的性能问题(如果有的话).