在API中暴露多少低级别内容？

在设计通用库的公共API时，应该暴露多少内部使用的低级内容？一方面，用户不应过分依赖实现细节，太多低级函数/类可能会混淆API。因此，下跪反应可能是“无”。另一方面，一些低层次的功能可能对人们有用，而更多的低层功能可能会阻止抽象倒置（在高层次结构之上重新实现底层结构）。在API中暴露多少低级别内容？

此外，公开更多低级别细节可以提供性能快捷方式。例如，假设您有一个函数来查找数组的中位数。令人惊讶的原则是你应该复制数组，以便API的用户不必关心它的实现涉及重新排序元素的副作用。在这种情况下，你是否应该注意到，median（）会花费内存分配，并提供绕过分配的另一个函数，但会随意对用户的输入进行重新排序？

什么是这种类型的细节暴露多少的一般准则？

来源

2009-01-10 dsimcha

关于你的中位数（）的例子，解决方案是文件。首先提供最不令人意外的方法，那么，如果出现性能需求，则提供第二种方法，不要分配和记录其行为 – 2009-01-10 14:53:00

尽可能少。

您揭露的细节越多，更改可能会破坏消费者。

来源

2009-01-10 14:44:59

你的API不应允许调用者通过破坏内部状态（例如重新排序集合等）来“破坏”任何东西。为了解决这个问题，只有在必要时才能读取暴露的接口。

关于复杂性，我倾向于简单的基本方法。我非常努力地不要过度设计任何我认为需要的东西。

写今天的要求（也许明天的），但不能超越。您可以随时扩展。抛弃你无法再维护的东西更难。

来源

2009-01-10 14:47:19

这样做的unix方式是提供机制，而不是政策。只要提供正确的工具来做事情（比如说一把刀），但尽量不要预测它们将如何使用（剥苹果或磨铅笔）。

来源

2009-01-10 15:00:18 PolyThinker

您可以详细说明这一点吗？我真的不明白你在说什么。 – dsimcha 2009-01-10 16:53:15

我听过一种表达方式：公开什么，但不是如何。

我们的目标是为客户提供一个有用且丰富的库，使它们不依赖于库的内部。你希望能够改变内部结构，而不会打断调用者（就像其他人已经注意到的那样）。

写一个好的API涉及到一定数量的巧妙边缘。

来源

2009-01-10 20:24:18

在API中暴露多少低级别内容？

回答

相关问题