过度工程API的动机？

Question

对于可怕的过度设计的API来说似乎有很多不喜欢的东西，这些API被设计为无限灵活，因此不会使简单的事情变得简单。尽管如此，似乎并不缺少需要您使用8个不同类并编写20行样板文件来完成简单常见任务的API。我不会提到名字，因为这不应该是关于特定API是否过度设计的火焰。

您认为这些可怕的过度工程API的根本原因是什么？您认为阻止API设计人员制造此类怪物需要做些什么？

编辑：恕我直言，甚至创建可重复使用的代码都不是一个好的答案，因为如果API难以使用且需要大量的样板，那么重用的好处就会变得有问题。

Answer 1

我认为这通常是所谓的Second System Effect的结果。设计师从他们的第一次“版本1”设计中汲取经验教训，使下一版本变得更加灵活，变得过度设计，难以理解。

弗雷德布鲁克斯的书The Mythical Man-Month介绍了这个术语并详细讨论了它。

Answer 2

所有邪恶的根源是开发人员不是a）聪明/有经验，b）足够充足。

Answer 3

我不确定这些是否是过度工程或抽象不足的情况。 windows api就是一个很好的例子。

曾几何时，我花了大量时间编写打印和预览引擎。我不得不解码在屏幕上显示内容并输出到打印机所需的windows api调用。在创建api抽象时，我试图考虑开发人员试图完成的事情......例如： “我想从坐标（1,1）到（8,1）绘制1点宽的红线 - 用英寸表示。”

等效的windows api涉及许多很多恼人的代码行...创建画笔，将其选择到设备上下文中，设置起点，处理从英寸到像素的转换，绘制到终点，我抽象的api只需一个电话： dpLine（documentHandle，x1，y1，x2，y2，width，color）; //其中x1，x2，y1，y2以英寸

表示

在这种情况下，我认为windows gdi api的级别太低了。我确信他们所做的事情有充分的理由，并且没有时间/精力为可能使用它的程序员创建一个合适的界面。怪物的原因可能只是时间限制。 api在技术上是准确的;它允许程序员做他们需要的事情。这足以运送它。但是，它是如此之低，以至于第三方抽象是必要的，以使其可用。 IMO，你可以为操作系统做一个论证，提供一个像这样的低级复杂api，但第三方工具不应该那么复杂。

-Don

Answer 4

  

“过早优化是所有邪恶的根源。”   
  --Don Knuth

即便如此，这也非常非常诱人，因为程序员本能地喜欢效率和聪明。

Answer 5

第二次系统效应？

Answer 6

我认为没有什么能阻止人们过度思考问题。它是解决问题的固有方法。像XP这样的方法试图阻止它，但是当它归结为它时，每个人都会想“但如果我把它变得更通用，那么我可以在这样的时候重复使用它”

Answer 7

我认为Python遭受了二次系统效应。在版本2.x中，存在两种类型和不同的语义。

希望Python 3.0解决了大部分问题。