在设计通用库的公共API时，应该公开多少内部使用的低级内容？一方面，用户不应过分依赖实现细节，太多的低级函数/类可能会使API混乱。因此，膝跳反应可能是“无”。另一方面，一些低级功能可能对人们有用，并且暴露更多功能可以防止抽象反转（在高级构造之上重新实现低级构造）。
此外，暴露更多低级细节可以提供性能快捷方式。例如，假设您有一个函数来查找数组的中位数。最少惊喜的原则是你应该复制数组，以便API的用户不必关心它的实现涉及重新排序元素的副作用。在这种情况下，您是否应该注意，median（）会占用内存分配并提供绕过分配的另一个函数，但会随意重新排序用户的输入？
有哪些一般指导方针可以公开这种细节的多少？
答案 0 :(得分：2)
尽可能少。
您公开的细节越多，更改就越有可能打破消费者。
答案 1 :(得分：2)
您的API不应允许呼叫者通过弄乱内部状态（例如重新排序集合等）来“破坏”任何内容。要解决这个问题，只有在必要时才能读取暴露的接口。
关于复杂性，我倾向于简单，基本的方法。我非常努力，不要过度使用我认为将来需要的任何东西。
写出今天的要求（也许是明天的要求），但不能超越。您可以随时扩展。放弃你不能再维护的东西要困难得多。
答案 2 :(得分：1)
unix的做法是提供机制，而不是策略。只需提供正确的工具（比方说，刀），但尽量不要预测它们将如何使用（剥苹果或削铅笔）。
答案 3 :(得分：1)
我听到它表达的一种方式：公开什么，而不是如何。
目标是为客户提供有用且丰富的库，而不依赖于库的内部。您希望能够在不破坏呼叫者的情况下更改内部结构（正如其他人已经注意到的那样）。
编写一个好的API涉及一定数量的艺术边缘政策。