Java interface to understand

Spring for some time to learn, but also have a little understanding of java, most can not understand is the interface, even if the interface is written and implemented it, still can not understand it in the end what's the use? I looked at several other blog, summed up his understanding.

Abstract type is a JAVA programming language is a set of abstract methods. Interfaces inherit a class manner, thereby inherit the abstract interface methods.

Start with a popular explanation looks (original: C # Interface "popular explanation" )


If your job is to repair a water pipe of the day you get your customers to find the help install water pipes, but there is a requirement that customers prefer the tube is triangular.

You buy a triangle of water flew back, get hold of a triangular hole in the wall, the customer paid the money, you are very happy today with the income, as shown below, well:

280101020477366.png

But did not last long, a week later another customer came, because he felt that the triangle does not look good, make you into a square pipe, you have to change, because the customer is God. Well, to continue to get hold of a square hole in the wall and then into the square pipe to connect. Well, as shown :( but may feel why did not say to the square? Because the demand is always changing ...)

280104040472031.png

You tired sweating, but still finished. Unfortunately, soon after, the client has come to you, because he wanted to replace the oval tube. While you are helpless, but you still have to spend a few hours to complete. As shown below:

280105478602182.png

The installation is complete, then you might consider why the change of pipes of different shapes, some of it I have to go to war? So you think of a good way, that is a fixed pipe wall design and is round, what shape when water customers like it, then I just need customers like the pipes of a rounded-off, so the future You do not need to touch the wall of the pipe. This is a good way. Get hold of the wall on the first round of the mouth, the mouth is called interface. As shown below:

280109385166981.png

As you can see, the wall has a circular mouth, but according to the original:

Triangular pipe ends are triangular
square pipe ends are square
ends elliptical oval tube

It was certainly not on the ground, as the triangle, square, oval and round mouth how the docking port on the wall it?

So first implement the interface, to:

三角形水管一端做成圆形
正方形水管一端做成圆形
椭圆形水管一端做成圆形

如图,所以,圆形接口做出来了,具体实现是客户去安装,接口本身并不会安装其他形状的水管,换句话说就是接口没有具体实现,只是告诉你,你的水管要接入,必须有一端是圆形的(接口的约束),因为我只留这个圆形的接口,你要装别的形状的管子,先把一个弄成圆形的就好了(子类去实现接口的方法),不管什么形状,都要一个必须做成圆形才能对接得上,它必须要你按照我的规范来做。这就是为什么新手会觉得接口什么都不做,只定义接口,没有任何实现,那不是多此一举吗?因为它的实现是子类去完成。这样只要客户喜欢什么形状的水管,只要实现了我的接口(圆形),都能对接得上,而且改变起来也很方便,只要把水管扭上去就行了,不用在去给墙壁挖洞了。


初步了解接口,再用代码进一步理解

需求:公司有两个人分别写了2个动物类,让你写一个类来输出它们各自喜欢的食物。

//A写的Dog类,里面有个likeFood方法
class Dog 
{

    public void likeFood() { Print("我是小狗,我喜欢吃肉"); } } //B写的Cat类,里面有个likeFood方法,如下: class Cat { public void likeFood() { Print("我是小猫,我喜欢吃鱼"); } }

你写的Zoo类如下:

//动物园类
class Zoo {

    public void show(Dog dog){ dog.likeFood(); } public void show(Cat cat){ cat.likeFood(); } }

在输出的时候使用如下:

void Main() 
{
    Zoo zoo = new Zoo();
    zoo.show(new Dog()); //"我是小狗,我喜欢吃肉" zoo.show(new Cat()); //"我是小猫,我喜欢吃鱼" }

这一切工作良好,但好景不长,公司又需要给动物园增加一个猴子,让C去写这个Monkey类,并能输出它喜欢的食物。


class Dog 
{

    public void likeFood() { Console.WriteLine("我是小狗,我喜欢吃肉"); } } //B写的Cat类,里面有个likeFood方法,如下: class Cat { public void likeFood() { Console.WriteLine("我是小猫,我喜欢吃鱼"); } } //C写的Monkey类,里面有个likeFood方法,如下: class Monkey { public void likeFood() { Console.WriteLine("我是猴子,我喜欢吃桃子"); } }

于是你的Zoo类就变成了这样,仅仅多了一个重载方法:

class Zoo 
{
    public void show(Dog dog) { dog.likeFood(); } public void show(Cat cat) { cat.likeFood(); } public void show(Monkey money) { money.likeFood(); } } void Main() { Zoo zoo = new Zoo(); zoo.show(new Dog()); //"我是小狗,我喜欢吃肉" zoo.show(new Cat()); //"我是小猫,我喜欢吃鱼" zoo.show(new Monkey()); //"我是猴子,我喜欢吃桃子" }

虽然只是增加了一个类,但善于思考的你马上就会想到:“如果后面还有更多动物要输出它们喜欢的食物,我的Zoo类都要修改,这对我来说不是一件好事。”
仔细观察Zoo类,发现不变的是show方法,变化的是show方法是参数。因为每个动物都不一样,所以参数也就不一样。所以原来就需要重载多个方法。
如果有一个类,能接收所有动物,那不就解决了?没错,于是你想到了定义一个父类叫Animal,里面有个likeFood方法,让所有动物类去继承Animal。

class Zoo 
{

    public void show(Animal animal) { animal.likeFood(); } } class Animal { public void likeFood() { Print("我是Animal类"); } }

你告诉原来的A和B两人,让它们写的动物类都去继承Animal,并且里面有个输出动物喜欢食物的方法。

class Dog : Animal 
{

    public void likeFood() { Print("我是小狗,我喜欢吃肉"); } } class Cat : Animal { public void likeFood() { Print("我是小猫,我喜欢吃鱼"); } } class Monkey : Animal { public void likeFood() { Print("我是猴子,我喜欢吃桃子"); } }

运行也一切良好,不管你以后还有什么类,只要让需要添加的动物类,继承Animal,并有个likeFood方法,那么你无需修改Zoo,只需要再main方法里传入动物类的实例就能正常工作。
你大赞你聪明绝顶,这样一来,你的Zoo根本不需要改变了。
有一天,公司新来一个人,暂时叫D吧,公司让D写个兔子类,你告诉D,你写的Rabbit类必须继承Animal,并且有一个它喜欢的食物的方法。

class Rabbit : Animal 
{

    public void favoriteFood() { Print("我是兔子,我喜欢吃萝卜"); } } void Main() { Zoo zoo = new Zoo(); zoo.show(new Dog()); //"我是小狗,我喜欢吃肉" zoo.show(new Cat()); //"我是小猫,我喜欢吃鱼" zoo.show(new Monkey()); //"我是猴子,我喜欢吃桃子" zoo.show(new Rabbit()); //"我是Animal类" }

Raabit并没有输出预想的结果,你不得不花了点时间去排查原因,最后你发现这不是什么大问题,因为新来的D虽然写了Rabbit类,但是他并不知道你们之前约定的动物喜欢的食物命名为:likeFood()
D写的Rabbit类,里面的方法叫:favoriteFood()
虽然最后D修改他的Rabbit类的方法为likeFood(),但你还是对这个问题做了一番思考,为什么会导致这个问题?
那是因为没有一种约束,使得子类继承父类的时候必须实现父类的方法。有没有一个类,能让它的子类必须实现它定义的方法?有,那就是接口
于是你修改Animal为接口,代码如下:

interface Animal {

    public void likeFood(); }

总结

由上述的例子可以总结接口的几个用处:

  1. 使代码易于维护,不管增加多少动物类,只要实现了animal接口,就都能拿来用
  2. 制定一种标准和规范,减少命名不统一带来的一系列问题
  3. 方便团队开发,设计者不用关心具体方法的实现,实现者可以清楚地知道自己的任务是什么。

There is also a problem: when I write code, there are the first method, the object, and then there are classes, then go into the abstract interface, then every one of my classes need to interface to abstract it? During development, each must write a method to write its interface of abstract methods to achieve its serviceTest and call it controllerTest, finally can really put the program to use, even a small function have to do a lot of "wasted effort", but once demand change, not change up more trouble?

Guess you like

Origin www.cnblogs.com/otakus/p/12169072.html