软件设计23丨接口隔离原则：接口里的方法，你都用得到吗？

在前面几讲中，我们讲的设计原则基本上都是关于如何设计一个类。SRP 告诉我们，一个类的变化来源应该是单一的；OCP 说，不要随意修改一个类；LSP 则教导我们应该设计好类的继承关系。

而在面向对象的设计中，接口设计也是一个非常重要的组成部分。我们一直都在强调面向接口编程，想实现 OCP 也好，或者是下一讲要讲的 DIP 也罢，都是要依赖于接口实现的。

也许你会说，接口不就是一个语法吗？把需要的方法都放到接口里面，接口不就出来了吗？顶多是 Java 用 interface，C++ 都声明成纯虚函数。这种对于接口的理解，显然还停留在语法的层面上。这样设计出来的只能算作是有了一个接口，但想要设计出好的接口，还要有在设计维度上的思考。

那什么样的接口算是一个好接口呢？这就需要我们了解接口隔离原则。

接口隔离原则

接口隔离原则（Interface segregation principle，简称 ISP）是这样表述的：

不应强迫使用者依赖于它们不用的方法。

No client should be forced to depend on methods it does not use.

这个表述看上去很容易理解，就是指在接口中，不要放置使用者用不到的方法。站在使用者的角度，这简直再合理不过了。每个人都会觉得，我怎么会依赖于我不用的方法呢？相信作为设计者，你也会同意这种观点。然而，真正在设计的时候，却不是人人都能记住这一点的。

首先，很多程序员分不清使用者和设计者两个是不同的角色。因为在很多人看来，接口的设计和使用常常是由同一个人完成。这就是角色区分意识的缺失，这种缺失导致我们不能把两种不同的角色区分开来，本质上来说，这也是分离关注点没有做好的一种体现。

实际上，很多程序员在开发过程中，其实是两种角色都没有的，他们根本没有思考过接口的问题，因为他们更关心的是一个个的具体类。只有到了必须的时候，接口才作为语法选项使用一次，这种做法干脆就是没在设计上进行思考。

然而，你不设计接口，并不代表没有接口。

在做软件设计的时候，我们经常考虑的是模型之间如何交互，接口只是一个方便描述的词汇，为了让我们把注意力从具体的实现细节中抽离出来。但是，如果没有设计特定的接口，你的一个个具体类就变成它的接口。同设计不好的接口一样，这样的“接口”往往也是存在问题的。

那接口设计不好会有什么问题呢？典型的问题就是接口过“胖”，什么叫接口过“胖”呢？我给你举个例子。

胖接口减肥

假设有一个银行的系统，对外提供存款、取款和转账的能力。它通过一个接口向外部系统暴露了它的这些能力，而不同能力的差异要通过请求的内容来区分。所以，我们在这里设计了一个表示业务请求的对象，像下面这样：

class TransactionRequest {

// 获取操作类型

TransactionType getType() {

...

}

// 获取存款金额

double get