处理新API(库,类,等等)的标准方法通常如下所示：

>您考虑API用户需要哪些方法
>您实施了您怀疑用户需要的API

所以基本上你试图猜测你的API应该是什么样的.它经常导致过度工程化的东西,你认为用户需要的巨大的API,你很可能根本不会使用你的大部分代码.

前段时间,甚至可能是几年,我读了一些促进编写客户端代码的文章.我不记得我在哪里找到它但作者指出了几个优点,比如更好地理解API将如何使用,它应该提供什么以及什么基本上已经过时.我认为这与SCRUM方法和用户故事相关,但在实现层面上.

出于对我最新私人项目的好奇,我开始没有使用实际的API(某种工具包库),而是使用此API的客户端代码.当然我的代码都是红色的,因为类,方法和属性不存在,我可以忘记intellisense的帮助,但我注意到,经过几天的编码,我的应用程序“有”所有基本功能和我的库API“是“比我在开始一个项目时想象的要小很多.

我不是说,如果有人拿走我的库并开始使用它,它不会缺少一些功能,但我认为它帮助我意识到我对这个API的想法有些缺陷,因为我通常试图覆盖所有基础并提供方法“以防万一”.有时它会让我感到非常伤心,因为我在基本功能方面犯了一些愚蠢的错误,更多地关注某些人可能需要的代码.

所以我想问你,你是否曾经在创建一个新的API时尝试过这种方法,并且它对你有帮助吗？这是一种有名的公认技术吗？

最佳答案

So basically you’re trying to guess what your API should look like.

这是以这种方式设计任何东西的最大问题：在软件设计中应该没有(好的,最小的)猜测.基于假设而不是实际信息设计API是危险的,原因如下：

>这与YAGNI的原则直接相反：为了完成任何事情,你必须假设用户将需要什么,没有信息来支持这些假设.
>当你完成了,并且你最终开始使用你的API时,你总会发现使用它很糟糕(用户体验不佳),因为你没有考虑如何使用这个库(UX),你正在考虑图书馆必须做什么(功能).
>根据定义,API是用户(即开发人员)的接口.设计其他任何东西只会造成糟糕的设计,而不会失败.

编写示例代码就像在编写后端之前设计GUI：一件好事.它迫使您考虑用户体验和设计决策的实际效果,而不会陷入无用的理论和假设之中.

与加布里埃尔的回答相反,这不是自下而上的设计：它是自上而下的.您不是设计库的具体后端,然后在其上强制使用抽象接口,而是首先设计接口,然后担心实现.