接口的概念
接口隔离原则:
- 一个类对另外一个类的依赖性应当是建立在最小的接口上的
- 一个接口代表一个角色,不应当将不同的角色都交给一个接口。没有关系的接口合并在一起,形成一个臃肿的大街口,这是对角色和接口的污染。因此使用多个专门的接口比使用单一的总接口要好
- 不应该强迫依赖于它们不用的方法。接口属于客户,不属于它所在的类层次结构,既不要强迫客户使用它们不用的方法,否则这些客户就会面临由于这些不使用的方法的改变带来的改变
接口隔离原则的应用
只提供调用者需要的方法,屏蔽不需要的方法
电子商务系统,该系统中有订单这个类,并在三个地方使用到订单类:
- 一个是门户,只能有查询方法
- 一个是外部系统,有添加订单的方法
- 一个是管理后台,添加、删除、修改、查询都要用到。
针对这三种不同的应用场景,为了满足接口隔离原则,应使用是三个不同的接口进行隔离,每个接口中提供的方法不同,这样使每个应用都建立在最小接口上
//用户门户应用接口
public interface IOrderForportal {
public String getOrder();
}
//外部系统应用接口
public interface IOrderForOtherSys {
public void insertOrder();
}
public interface IOrderForAdmin {
public String getOrder();
public void insertOrder();
public void updateOrder();
public void deleteOrder();
}
public class Order implements IOrderForAdmin, IOrderForportal, IOrderForOtherSys {
public static IOrderForportal getOrderForportal() {
return new Order();
}
public static IOrderForOtherSys getOrderForOtherSys() {
return new Order();
}
public static IOrderForAdmin getOrderForAdmin() {
return new Order();
}
@Override
public String getOrder() {
// TODO Auto-generated method stub
return "返回订单";
}
@Override
public void insertOrder() {
// TODO Auto-generated method stub
System.out.println("插入订单");
}
@Override
public void updateOrder() {
// TODO Auto-generated method stub
System.out.println("更新订单");
}
@Override
public void deleteOrder() {
// TODO Auto-generated method stub
System.out.println("删除订单");
}
}
public class TestISP {
public static void main(String[] args) {
IOrderForportal op = Order.getOrderForportal();
System.out.println(op.getOrder());
IOrderForOtherSys os = Order.getOrderForOtherSys();
os.insertOrder();
IOrderForAdmin oa = Order.getOrderForAdmin();
oa.deleteOrder();
oa.insertOrder();
oa.updateOrder();
oa.getOrder();
}
}
接口隔离原则是对接口的定义,同时是对类的定义,应尽量使用原子接口或者原子类,其中:“原子”在实践应用中可以根据以下结果规则来衡量:
一个接口只对一个子模块或者业务逻辑进行服务
只保留接口中业务逻辑需要的public方法
尽量修改污染了的接口,若修改的风险较大,则可采用适配器模式进行转化处理
接口设计应因项目而异,因环境而异,不能教条照搬
带来的好处:
设计的灵活性,并降低真个项目风险,当业务变化时能够凯苏应付。在设计接口时应根据经验和常识决定接口的粒度大小,如果接口粒度太小,导致接口数量剧增,给开发带来难度;如果接口粒度太大,灵活性较低,无法地宫定制服务,给项目带来无法预计的风险