太多的抽象会是不好的吗？

Question

作为程序员，我觉得我们的目标是为给定的领域模型和业务逻辑提供良好的抽象。但是，这种抽象应该在哪里停止呢？如何在抽象和它的所有好处(灵活性、易变性等)之间进行权衡。以及易于理解代码和它的所有好处。

我认为我倾向于编写过于抽象的代码，我不知道它有多好；我常常倾向于把它写成某种微观框架，它由两部分组成：

1. 微模块连接在微框架中:这些模块很容易理解、开发和维护为单一的单元。这段代码基本上代表了实际执行功能内容的代码，在需求中描述了这一点。
2. 连接代码；现在我认为这里存在问题。这段代码往往很复杂，因为它有时非常抽象，一开始很难理解；这是因为它仅仅是纯粹的抽象、实际中的基础和业务逻辑在所提供的代码中执行；从这个原因出发，这些代码在测试后不会被更改。

这是一个很好的编程方法吗？它的变化代码在许多模块中非常零散，很容易理解，而从抽象的POV来看，不改变的代码非常复杂？如果所有的代码都是一致复杂的(即代码1更复杂和相互链接，代码2更简单)，以便任何人在合理的时间内了解它，但是更改是昂贵的，或者上面提出的解决方案是好的，其中“更改代码”非常容易理解、调试、更改和“链接代码”是一种困难。

注意:这与代码可读性无关！在1和2处的代码都是可读的，但2处的代码具有更复杂的抽象，而代码1则带有简单的抽象。

Answer 1

C++编程语言，第4版的第一个词是：

计算机科学中的所有问题都可以通过另一个层次的间接解决，除了太多的间接问题。-戴维·惠勒

(大卫·惠勒是我的论文导师。没有重要的最后一行的引文有时被称为“计算机科学的第一定律”。

Answer 2

是的，当然。问题是，没有什么抽象是完美的。抽象层的所有细节都是有原因的，它可以简化很多事情，但是如果在某个时候不需要这样的复杂性，那么它可能一开始就不会存在。这意味着在某种程度上，每个抽象都会以某种方式泄漏。

这才是真正的问题所在。当抽象失败时，您编写的代码与实际发生的代码之间的层次越多，就越难解决和解决问题，因为有更多的地方可能会出现问题。有越多的层，你就越需要知道才能找到它。

Answer 3

是的绝对是。

我喜欢用一个比喻来解释程序设计，那就是Tailor。在做西服时，一个好的裁缝者总是会把少量的布料留在衣服内的战略位置，这样衣服就可以被拿进去，或者穿出去，而不会改变衣服的整体形状或结构。

好的裁缝不要在每个接缝上留下大量的布料，以防你碰巧长出第三只手臂，或者怀孕。太多的材料在错误的地方会使一个不合适的，和穿着不良的衣服，额外的织物只是得到了正常使用的方式。对小面料和服装是容易流泪的，将无法改变，以应付其穿着者的身体小变化，影响服装的坐姿。

也许有一天，我们的好裁缝会被指派做一件如此紧身的衣服，以至于必须把它缝在里面。也许我们的好裁缝被要求做孕妇装，在那里的风格和适合是第二舒适和扩展能力。但在从事任何一项特殊工作之前，一位优秀的裁缝将足够明智，让每个人都意识到为实现这些目标而做出的妥协。

有时，这些妥协是正确的道路，人们愿意接受其后果。但在大多数情况下，在最重要的地方离开一点的做法将超过任何感知到的好处。

所以，把它和抽象联系起来。它绝对有可能有太多的抽象层，就像它有可能从少到少。程序员的真正艺术，就像我们的裁缝朋友一样，就是把它放在最重要的位置。

回到话题上。

代码的问题通常不是抽象，而是依赖。正如您已经指出的，连接离散对象的代码是一个问题，因为它们之间存在隐式依赖关系。在某种程度上，事物之间的交流需要是具体的，但是判断这一点在哪里通常需要一些猜测。

也就是说，"Micro“任何东西通常都表明您已经过度细化了对象布局，并且可能正在使用Type作为数据应该是什么的同义词。拥有更少的东西也意味着它们之间通信所需的依赖性更少。

出于这个原因，我非常喜欢系统间的异步消息传递。最后，两个系统依赖于消息，而不是彼此。减少了通信系统之间的紧密耦合。在这一点上，如果您需要在系统之间有一个依赖关系，您需要考虑是否在正确的位置上有依赖的位(S)。通常情况下，你不会。

最后，复杂的代码将是复杂的。这往往是无法避免的。但是，与依赖于各种外部状态的代码相比，依赖较少的代码更容易理解。