设计原则：接口隔离原则(ISP)

接口隔离原则的英文是Interface Segregation Principle,缩写就是ISP。与里氏替换原则一样其定义同样有两种

定义1：

Clients should not be forced to depend upon interfaces that they don'tuse.

(客户端被强迫不应该依赖它不需要的接口。)

定义2：

The dependency of one class to another one should depend on the smallest possibleinterface.

(类间的依赖关系应该建立在最小的接口上。)

这两种定义相比较，我更喜欢它的第一种定义。其中最重要的概念就是“接口”，这里的接口其实不仅仅是指OOP概念中的接口，其小到类所暴露出来的public方法、所提供的公共属性，大到业务上一组API的组合，甚至系统对外所提供的服务，都可以称之为接口，接口是一种抽象的约定。而客户端可以理解为接口的调用者或者使用者。

这个表述看起来很容易，但是在真正设计中却很难，在大多数的项目里，也是经常被违背的原则之一，因为设计者往往很难站在使用者的角度上去看待问题，甚至有很多设计者根本没有接口的概念，他们往往只从类的角度上去思考问题，而在类设计完毕后，而为了使用接口象征性的增加一个接口，然后把类的方法签名搬到接口里而已。(我们可以想想，自己在项目中是不是也是先写类，后写接口呢?)

2.如何理解并运用好接口隔离原则

接口隔离原则要求我们尽量提供小而美的接口，而不是一个庞大臃肿的接口，以试图满足所有的调用者使用，它是对接口的的一种规范和约束。

其实在设计中想要运用好接口隔离原则，有一个好的办法，就是需要我们站在使用者的角度上去思考问题，按需去设计接口，我们可以通过几个例子来看一下

2.1 OOP中的接口隔离原则

现在，我们有一个商品系统，我想绝对多数的系统中都会按照下面这种方式进行接口的设计

它提供了CRUD操作供客户端调用。随着业务的不断发展壮大，我们发现商品访问的性能越来越差，数据库的压力也越来越大，这时我们需要对商品系统增加缓存的功能，但是有些场景下我们又需要能够实时的查询到商品系统，这种场景下应该怎么办？

public ProductInfo get(String id) {
	if(cache.contains(key)){
		return cache.get(key);
	}
	return productRepository.get()
}

public ProductInfo get(String id,boolean isCache) {
	if(cache.contains(key)&&isCache){
		return cache.get(