原文地址——I is for the Interface Segregation Principle——Donn Felker。
序曲的第四部，SOLID中的字母I代表的是接口隔离(The Interface Segregation Principle——ISP)。
如果你错过了前面三个乐章:
现在开始揭开序幕。
接口隔离原则
是这样描述的：
Make fine grained interfaces that are client-specific.
另外一个表述是：
Many client-specific interfaces are better than one general purpose interface.
Many client-specific interfaces?
第一次听说这个定义的时候，很难理解其中的含义——多接口？
其实也很容易理解，举个大家都很熟悉的Android例子——Android View。
据你所知，View是Android所有控件的超级父类(比如 TextView, Button,LinearLayout, CheckBox, Switch，等等)只要你叫得出名字的控件，其父类都是View。
假设你是20世纪中期Android的创造者之一，你知道大部分的控件都会被点击。所以，Java的最佳实践就是创建一个叫OnClickListener的接口嵌套在View中：
public interface OnClickListener {
void onClick(View v);
}
这看起来一定很熟悉。
随着Android版本的升级，你需要一个长按的监听器，最直接的方法是把长按的方法官方到OnClickListener中，像这样
public interface OnClickListener {
void onClick(View v);
void onLongClick(View v);
}
接下来，你又需要一个触碰的监听器，把它放到OnClickListener也无伤大雅对不对？
public interface OnClickListener {
void onClick(View v);
void onLongClick(View v);
void onTouch(View v, MotionEvent event);
}
这时，你决定将OnClickListener改一个名字叫ViewInteractions（或者其他），因为接口的功能已经不仅限于点击动作。
如果你不断往接口里面新增方法，就容易导致接口变得笨重，产生的问题是接口变得通用而且被污染。
被污染的接口问题
假设Android SDK使用上述的OnClickListener，我们就要这样来绑定按钮的点击事件：
Button create = (Button)findViewById(R.id.create);
create.setOnClickListener(new View.OnClickListener {
public void onClick(View v) {
// assume this is a todo based app.
myDatabase.createTask(...);
}
public void onLongClick(View v) {
// do nothing, we're not long clicking
}
public void onTouch(View v, MotionEvent event) {
// do nothing, we're not worried about touch
}
});
另外两个方法根本不需要使用。我只关心点击事件，而不是长按和触碰。当然在其他类中，可能需要全部的事件，但大多数情况，开发者只需要其中一种。
这个接口太通用了，即使开发者不需要，它也要求开发者覆盖所有的方法 。让我们重申ISP：
Make fine grained interfaces that are client-specific.
通过细颗粒度的接口定义，减少了接口被不必要的回调方法污染。作为调用者，我们只关注我们需要的方法，比如上述接口中，onLongClick和onTouch方法就是多余的。
感谢Google的家伙熟悉接口隔离原则。使用Android SDK的时候，我们无需过度继承OnClickListener，而只需要覆盖onClick方法。
// nested in the View class
public interface OnClickListener {
void onClick(View v);
}
如果开发者需要长按的监听，可以实现OnLongClickListner；需要触碰的监听，可以实现OnTouchListner。
每个接口都应该实现有特定的功能。
真实世界中的接口隔离原则
我有过不同的工作，在前几年的工作中，我碰到笨重的接口数量之多已经记不清了。一次我在开发SDK时，SDK的使用者必须实现一个重量级的接口，即使他们其实只需要其中一两个方法。34行代码可以解决的问题，就不需要写4060行。
当你想往接口里面新增方法时，扪心自问，是不是需要为调用者创造一个特定的接口。
有时候一个接口内可能有多个方法，这是可以的，例如TextView有一个叫 addTextChangedListener的方法。 TextWatcher提供三个方法：
public interface TextWatcher extends NoCopySpan {
public void beforeTextChanged(CharSequence s, int start, int count, int after);
public void onTextChanged(CharSequence s, int start, int before, int count);
public void afterTextChanged(Editable s);
}
这并不算是一个通用的接口，这些方法都是调用需要的特定功能接口，所以把它们打包成一个接口是对的。
结论
接口分离原则能更好地帮助应用的维护，更新和部署。我会为应用创建大量的接口，特别是我使用依赖注入（dependency injection，最后一篇介绍）。
如何使应用更好地调配？
想象你需要分离一个重量级的被污染的接口，这会使调用者的代码带来巨大的改动，特别是方法的签名。
接口隔离不仅仅是写SDK需要运用，写自己的应用时也不要忘记，特别在你创建抽象类和抽象API时。当你做这些抽象的时候，保证特定的功能和提高颗粒度，这样就减少了代码的混乱，容易维护。
享受编程的乐趣吧！期待整个系列的最后乐章。
