最小界面

最小界面是一种 API 设计风格，我在这里将其与 人性化界面 进行对比。最小界面的理念是设计一个 API，允许客户端完成所有需要完成的操作，但将功能简化为最小的合理方法集，以完成工作。（参见 人性化界面，了解差异的良好示例。）

使用 人性化界面 中的 ruby-array/java-list 示例，您不会在已经具有索引器和长度方法的列表类中包含 first 和 last 方法，因为您可以使用现有的接口来完成 first 和 last 操作。因此，first 和 last 是便利方法——极简主义者不会避免所有便利方法，但便利方法需要跨越很高的门槛才能进入。

对于 人性化界面 的论点已经存在，以下是最小界面的理由。

接口需要时间学习。一个具有庞大接口的类不太可能被很好地使用，并且可能一开始就让人反感。通过保持一组小而集中的方法，您可以让客户端更容易了解该类是什么以及它可以做什么。

这种专注对于类设计者也很重要。类设计中一个常见的问题是让类做太多事情。专注于基本要素有助于将杂物排除在类之外，使其能够专注于做好一件事并做好这件事。

如果您遵循人性化的方法，您如何知道在哪里停止？如果您不断添加方法，因为有人可能需要它们，那么您将拥有无穷无尽的方法。因此，您需要一些准则来避免这种方法爆炸。人性化的准则（提供有用的东西）是任意的且难以执行。极简主义的准则很简单——如果客户端可以使用现有方法完成操作，那么他们就不需要额外的操作。

（请注意，对于编写公开类库的人来说，找到有用内容的问题比应用程序代码更重要。对于应用程序代码，您知道您的用途——这是一个封闭系统。）

如果您使用静态类型纯接口（例如 Java 和 C# 中的 interface 关键字），那么另一个保持方法数量较小的原因是它减轻了实现者的负担。大量方法都需要实现，这需要大量工作。（使用抽象类作为 mixin 可以帮助减轻这种负担。）

如果您希望在最小类上获得更多功能，您可以使用其他类来实现。例如，在 Java 中，如果您希望反转或排序列表（Ruby 的 Array 上的常规方法），您可以使用 Collections 实用程序类。

当您在开发库时，一旦发布，就很难删除任何内容。因此，最好从太小的东西开始并添加内容，而不是在无法删除内容时拥有太大的东西。