过多的抽象会不好吗？

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

我相信我倾向于写过于抽象的代码，但我不知道它有多好。我经常倾向于将其编写为某种微型框架，包括两部分：

1. 连接在微框架中的微模块：这些模块易于理解，开发和维护为单个单元。这段代码基本上代表了实际执行功能的代码，如需求所述。
2. 连接代码；现在我相信这里是问题所在。该代码趋于复杂，因为它有时非常抽象，一开始很难理解。之所以会出现这种情况，是因为这仅仅是纯粹的抽象，实际上基础和业务逻辑是在所提供的代码1中执行的；因此，该代码一旦经过测试就不会更改。

这是编程的好方法吗？难道说，变更代码在许多模块中非常分散，并且很容易理解，而变更代码与抽象POV相比却非常复杂？如果所有代码都统一地复杂（即代码1更复杂和相互链接，而代码2更简单），以使通过它的任何人都可以在合理的时间内理解它，但是更改很昂贵，或者上述解决方案是好的， “更改代码”非常容易理解，调试，更改，“链接代码”有点困难。

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

TC ++ PL4的第一句话：

计算机科学中的所有问题都可以通过另一层间接解决，除非存在太多的间接层。–戴维·J·惠勒

（大卫·惠勒（David Wheeler）是我的论文顾问。有时没有重要的最后一行的引用有时被称为“计算机科学的第一定律”。）

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

这就是真正的问题所在。当抽象失败时，您在编写的代码和实际发生的事情之间分层使用的代码越多，找出问题并加以解决的难度就越大，因为可能存在更多的问题。而且层数越多，您必须了解的越多，以便对其进行追踪。

是的，一点没错。

我喜欢用来解释编程的类比是裁缝。制作西服时，好的裁缝师总是会在服装内的重要位置留下少量织物，以使服装可以进出，而无需改变其整体形状或结构。

好的裁缝不要在每个接缝处留下大量的织物，以防万一您碰巧长出第三只手臂或怀孕了。在错误的地方放置过多的材料会造成不合适的合身性，以及穿着不良的衣服，多余的织物只会妨碍正常使用。对于很少的织物，衣服容易流泪，将无法进行更改以适应穿着者体形的微小变化，从而影响衣服的坐姿。

也许有一天，我们的“好裁缝”将被要求做一件如此紧的衣服，以致不得不缝制衣服。也许我们的Good Tailor被要求制作孕妇装，其风格和合身性仅次于舒适性和可扩展性。但是在从事这两项特殊工作之前，优秀的裁缝将足够明智，以使每个人都意识到为实现这些目标而做出的妥协。

有时，这些妥协是采取的正确方法，人们愿意接受其后果。但是，在大多数情况下，在最重要的地方多花一点钱的方法会胜过任何可感知的收益。

因此，将其与抽象联系起来。它绝对可能有太多的抽象层，就像它可能有太多的方法一样。像我们的裁缝朋友一样，程序员的真正艺术是将最重要的地方留一点。

回到正题。

代码的问题通常不是抽象，而是依赖关系。正如您所指出的，连接离散对象的代码是一个问题，因为它们之间存在隐式依赖性。在某些时候，事物之间的交流只需要具体，但是判断该点通常需要一些猜测。

所谓“微”的东西通常表示您已经过度细化了对象布局，并且可能正在使用Type作为应为Data的同义词。拥有更少的东西也意味着更少的相互依赖关系。

因此，我非常喜欢系统之间的异步消息传递。您最终得到了两个依赖于该消息的系统，而不是彼此依赖。使您的通信系统之间的耦合不那么紧密。在这一点上，如果需要在系统之间建立依赖关系，则需要考虑是否在正确的位置依赖了位。而且通常情况是您不这样做。

最后，复杂的代码将变得复杂。通常没有办法解决。但是比起依赖于各种外部状态的代码，具有更少依赖性的代码要容易理解。

我觉得我们的目标是在给定的域模型和业务逻辑上提供良好的抽象。

我有不同的看法：我们的目标是解决业务问题。抽象只是组织解决方案的一种技术。另一个答案是使用裁缝制作衣服的类比。我还有一个想比喻的比喻：骨架。代码就像骨架，抽象是骨头之间的关节。如果您没有关节，那么您只剩下一条骨头，它根本无法移动并且毫无用处。但是，如果关节过多，就会出现一堆无法自立的草。诀窍是要找到合适的平衡点-足够的关节允许移动，但又不要太大，以至于没有实际定义的形状或结构。