接口到底有什么用

因为我开始也对这个问题很头疼，在想接口到底是用做什么的，加上又不会对结果造成什么影响，何不用一个方法类代替呢，我感觉这种方法固然是正确的。但是调用这个函数的人必须非常清楚的了解到这个函数的方法如何使用，我先传哪些参数进去？再通过什么方法将返回结果得到？所以对于个人来说这可能不是很大的问题，因为所有代码都是这一个人敲的嘛，~(￣0￣)/。但是对于一个团队协助开发时，如果要委托他人实现一个方法类的话， 我告诉他需求之后，他将方法类写出来，告诉我怎么调用balabala，但是调用时突然发现一个方法中我想传入的参数与需求的参数不同，我传入我想用的参数固然不行，之后找他去改时，他说：”啊？又要改，你当时不就这样子说的啊balabala“。可见，这一切都是由于之前我们并没有统一好到底该如何设计这个方法类，导致每个人跟每个人设计的方法类不同，用起来当然千差万别了。

但是当我们使用接口时，便可以规范函数设计，简化不必要的麻烦。比如我在设计一个动物百科时，需要知道每个动物怎么吃饭的，但是有些动物我并没有见过怎么办(╯﹏╰)，没关系，还有我们程序员小张啊，他可是见过大世面的人。所以我委托他来帮我写狗是如何吃饭的，但是之前，我设置了一个接口Animal，有一个方法叫eat()，我告诉小张，我需要狗狗是如何吃饭的（小张回我：用嘴 我：废话，你难道用菊花吗 (￣_,￣ )）。小张只需要新建一个Dog类声明Animal接口，在eat()方法里写狗狗是如何吃饭的，告诉我写完之后，我只需要 Animal dog = new Dog() 获得一个dog实例，调用dog.eat()即可知道狗狗是如何吃饭的啦，而并不需要关心eat()是如何实现的，这也是接口的一个好处，有利于协作开发。

可能上面讲的有点乱乱的，下面我再举一个实际点的例子。比如我现在是一个老板，想开一个超能力工厂（想想就激动ˋ( ° ▽、° ) ），但是里面什么都没有因为我什么都不会，可是我有钱啊(￣y▽￣)╭。我需要两台机器，一台能点石成金，一台能点石成银。于是我发布招标信息，经过层层筛选，最终选出了两家厂商给我生产这两种机器，但是我给他们的要求是，放入的石头必须是10cm*10cm大小的，厂家说没问题，只要你给钱10m*10m的都给你造出来（有钱真是好啊(￣y▽￣)╭）。半个月后，厂家交差，看着两台轰隆轰隆的机器，我只在入口处放入两块10cm*10cm的石头，之后轰轰一阵乱响，两台机器输出了金和银，于是我的创业梦就此开始了好激动ヾ(≧▽≦*)o 。

在这个例子里，超能力工厂就像你写的一个类Factory，你需要两个方法，changeStonetoGold,还有changeStonetoSilver。由于我并不会写（有人会写可以联系我(￣ ‘i ￣;) ），所以我委托例子中的厂商来让他们写，但是我有个条件是放入的石头必须是10cm*10cm大小的这就像接口中定义的方法stoneSize（）。两家厂商实现的方法必须调用我这个接口（因为我事先跟他们说，想要钱必须听我号令<(￣3￣)>）如果不告诉他们这个，机器可能入口千奇百怪，既不利于我生产，也不利于管理。这个接口中的方法就像是后来的机器的入口，我不管机器是如何工作的，我只知道会有个这样的入口，我放入石头就能给我变成金子而已。
所以综上，我觉得接口的几个优点：

1、提供一个规范。及调用这个接口必须满足我的某些条件
2、解决java中单继承的问题（如果我的厂子继承自一个点石成金机器工厂，但是我 想要其他的例如点石成银机器怎么办，所以通过接口来解决单继承问题）
3、可扩展性强。加入我以后想要个点石成玉的机器 ，我直接找到相应的厂商，告诉他接口，等机器制造出来，我直接实例化就可以生产了呀（又是一大笔钱 (￣y▽￣)╭ Ohohoho…..）
4、有利于协作开发。

我所理解的接口大概就是这样，它规定了一个规范，所有调用接口的函数必须符合我的规范，也就是实现我接口中的函数。