目的：通过将软件分为多个独立的部分来减少所需更改的副作用和频率。
笔者想到从两方面论述：
其一，在描述多种动物时，我们可能会将不同种类的动物分类。但是这还不够，例如在鸟类中，我们印象中鸟的特征是鸟会飞，但是企鹅不会飞~。
那么还要对物种的特征进行细分，例如血液是什么颜色的、有没有脊椎等。
其二，我们可以通过下面代码表达：
// 与登录有关
public interface IUserLogin
{
// 登录
void Login();
// 注销
void Logout();
}
// 与用户账号有关
public interface IUserInfo
{
// 新增一个用户
void AddUser();
// 修改一个用户的信息
void UpdateUser();
// 删除一个用户
void DeleteUser();
}
上面的两个接口，各种实现不同的功能，彼此没有交叉，完美。
接下来我们看看两个继承了 IUserLogin 接口的代码
// 对用户登录注销进行管理，资源准备和释放
public class Test1 : IUserLogin
{
public void Login(){}
public void Logout(){}
}
public class Test2 : IUserLogin
{
public void Login()
{
// 获取用户未读消息
}
public void Logout()
{
}
}
对于 Test1 ，根据登录和注销两个状态，进行不同操作。
但是，对于 Test2，它只需要登录这个状态，其它情况不关它事。那么 Logout() 对他来说，完全没有用，这就是接口污染。
上面的代码就违法了接口隔离原则。
但是，接口隔离原则有个缺点，就是容易过多地将细分接口。一个项目中，出现成千上万个接口，将是维护地灾难。
因此接口隔离原则要灵活使用，就 Test2 来说，多继承一个方法无伤大碍，不用就是了。ASP.NET Core 中就存在很多这样的实现。
public void Function()
{
throw new NotImplementedException();
}
《设计模式之禅》第四章中，作者对接口隔离原则总结了四个要求：
1 接口尽量小：不出现臃肿(Fat)的接口。
2 接口要高内聚：提高接口、类、模块的处理能力。
3 定制服务：小粒度的接口可以组成大接口，灵活定制新的功能。
4 接口的设计有限度：难以有固定的标准去衡量接口的粒度是否合理。
另外还有关于单一职责原则和接口隔离原则的关系和对比。
单一职责原则是从服务提供者的角度去看，提供一个高内聚的、单一职责的功能；
接口隔离原则是从使用者角度去看，也是实现高内聚和低耦合。
接口隔离原则的粒度可能更小，通过多个接口灵活组成一个符合单一职责原则的类。
我们也看到了，单一职责原则更多是围绕类来讨论；接口隔离原则是对接口来讨论，即对抽象进行讨论。
