大家都知道,在Java应用开发中,要“面向接口编程”,那么,对于接口的清晰理解尤为重要,尤其是对设计模式的学习。
在网上搜索了很多关于接口的定义,但是认识接口,还得从多个方面去理解,尤其是对接口的形象理解。
下面是摘自知乎和研磨设计模式:
一、
二、
接口就是个招牌。
(比如接口是饭店招牌,你进去都会看到挂在墙上或放在桌上的菜单,但至于同名菜式和同类饭店的味道是不是完全一样,服务是不是好,卫生够不够格,就看各家店的具体实现了。)
比如说你今年放假出去杭州旅游,玩了一上午,你也有点饿了,突然看到前面有个店子,上面挂着KFC,然后你就知道今天中饭有着落了。
KFC就是接口,我们看到了这个接口,就知道这个店会卖炸鸡腿(实现接口)。
(挂了KFC的招牌,我们不用进去就知道他家卖哪些食物,就可以直接去点炸鸡腿、黄金烤鸡腿堡。没有挂这个招牌,就算卖的东西和KFC一模一样,我们不进去看菜单就不会知道。)
那么为神马我们要去定义一个接口涅,这个店可以直接卖炸鸡腿啊(直接写实现方法),是的,这个店可以直接卖炸鸡腿,但没有挂KFC的招牌,我们就不能直接简单粗暴的冲进去叫服务员给两个炸鸡腿了。
要么,我们就要进去问,你这里卖不卖炸鸡腿啊,卖不卖汉堡啊,卖不卖圣代啊(这就是反射)。很显然,这样一家家的问实在是非常麻烦(反射性能很差)。
要么,我们就要记住,xx路108号卖炸鸡,xxx路45号卖炸鸡(硬编码),很显然这样我们要记住的很多很多东西(代码量剧增),而且,如果有新的店卖炸鸡腿,我们也不可能知道(不利于扩展)。
三、
接口只是一个规范,所以里面的方法都是空的。
假如我开了一个宠物粮店,声明所有宠物都可以来我这里买粮食,这就相当于一个接口,
public interface PetRestaurant {
public void buy();
}
当一只狗看到了,知道自己是宠物,所以它去实现这个接口
public class DogPet implements PetRestaurant {
@Override
public void buy() {
System.out.println("我是狗,我要买狗粮");
}
}
当一只猫看到了,知道自己也是宠物,所以也去实现这个接口
public class CatPet implements PetRestaurant {
@Override
public void buy() {
System.out.println("我是猫,我要买猫粮");
}
}
当狗和猫来我的店之前,我是不知道他们到底是什么,但是当他们来到我的店,我就知道一个要猫粮食,一个要狗粮食。因为他们都实现了 我这个接口,都可以买。下面这个类相当于一个接待顾客的类,即店小二,他接待所有实现了我这个宠物店接口的动物,传进来一个PetRestaurant 类型的宠物,注意,这个PetRestaurant 是接口
public class test {
public void buy(PetRestaurant pet)
{
pet.buy();
}
}
好了,这个时候我这个老板出现了,我可以给他们卖粮食了,相当于测试类
public class Tests {
public static void main(String[] args) {
PetRestaurant dog = new DogPet(); //实例化一个狗,相当于把狗顾客实例化
PetRestaurant cat = new CatPet();//实例化一个猫,相当于把猫顾客实例化
test t = new test(); //实例化一个店小二
t.buy(cat); //把猫交给店小二
t.buy(dog); //把狗交给店小二
}
}
这样运行的结果就是
我是猫,我要买猫粮
我是狗,我要买狗娘
你知道吗,整个过程我这个店主其实根本不知道来的到底是猫是狗还是其他什么,我只要有一个店小二,把这些来的不知什么动物都全部交给店小二,店小二就知道怎么去卖了,因为这些狗啊猫啊都实现了我这个宠物店的接口,而店小二就负责接待所有实现了我这个接口的动物。这就有一个好处,假如明天来了一头小猪,只要它实现了我这个接口,我只管交给店小二处理就OK了,我这个店小二根本不需要变化,我这个店主也只需要实例化一下这个动物就OK
你想,假如没有接口,会怎么办,来一个猫,我要去创造一个猫,还要实例化,来一只狗,我要创建一只狗,同样要实例化,还要配备专门的店小二去接待,就会相当麻烦。