问增加类的数量会增加代码的复杂性吗？

EN

衔接性和耦合是两个相关的术语，但由于它们的矛盾性质，不可能有固定的答案。

内聚

衔接是衡量一个阶级的方法起多大作用的尺度。如果你有很高的内聚力，那么你的大多数方法都对类似的事情负责，而如果你的内聚力很低，那么这些方法或多或少是独立的。这与单一责任原则 (SRP)略有关联，它告诉我们您应该以高凝聚力为目标。

耦合

与衔接不同，耦合是指模块/类之间的相互依赖关系。如果您有高耦合，这意味着您的模块之间交互频繁，而低耦合意味着只有很少的交互，即小接口。同样，很容易看出低耦合更好。

矛盾

同时实现高内聚性和低耦合性的问题是，将代码更改为改进一个意味着减少另一个代码。

作为一个简单的例子，将所有的功能都包含在一个类中。这意味着你有极低的耦合，这是好的！当然，你的内聚力也很低，因为你班上的所有方法都要做不同的事情。

在另一个极端，考虑将事物分割成许多类，每个类只包含一个小方法。这意味着你有很高的内聚力，这也是很好的，但是要做实际的工作，这些方法必须访问很多其他类。这些依赖关系也意味着您得到了非常高的耦合，这也不是很好。

权衡

本质上，你最终会有一个权衡:专注于内聚力，而在耦合上输掉。专注于耦合，你就会失去凝聚力。要做出一个很好的选择，在权衡尺度上，耦合和内聚力本身是不够的。相反，您应该查看代码质量的其他标准，并查看它们所带来的范围。

例如，SRP为您提供了良好的内聚力，并且有一些人主张这是唯一的真理，但当然，如果您非常严格地遵循SRP，您最终会得到大量的类和高度耦合。有时候，你可能会发现所有这些耦合都给你带来了很多麻烦。在这种情况下，您可能会证明，通过违反SRP来降低耦合的代价是值得的(或者让我们简单地说，重新解释这个单一响应是什么)。

作为一种最佳实践方法，我相信SRP是一种储蓄赌注。一般来说，高耦合比低内聚更有问题，因为我们发现处理本地化于一个类(内聚)的问题更容易。因此，如果您遵循SRP，它将引导您进入折衷规模的低耦合端，这至少是一个很好的起点。

我通常每个表都有一个类，加上枚举字段所需的枚举，再加上数据服务和用户控件等等。我得到的唯一的WTF来自用户，尽管这个比率是以小时而不是分钟来衡量的。

由于没有关于语言细节的讨论，所以我只能按照我在C#中所做的进行讨论。我通常尝试创建高度可重复的设计模式，这样查看一个类的人就可以在其他类中找到类似的东西。考虑到我的设计规则，我不知道我怎么能“减少这个数字”。