第一章 接口

1.1接口概念

接口是功能的集合，同样可看做是一种数据类型，是比抽象类更为抽象的”类”。

接口只描述所应该具备的方法，并没有具体实现，具体的实现由接口的实现类(相当于接口的子类)来完成。这样将功能的定义与实现分离，优化了程序设计。

请记住：一切事物均有功能，即一切事物均有接口。

1.2接口的定义

 

与定义类的class不同，接口定义时需要使用interface关键字。

 

定义接口所在的仍为.java文件，虽然声明时使用的为interface关键字的编译后仍然会产生.class文件。这点可以让我们将接口看做是一种只包含了功能声明的特殊类。

 

定义格式：

　　　　public interface 接口名 {                         

　　　　抽象方法1;                                                                           

　　　　抽象方法2;

　　　　抽象方法3;

　　　　}

使用interface代替了原来的class，其他步骤与定义类相同：

• 接口中的方法均为公共访问的抽象方法
• 接口中无法定义普通的成员变量

1.3类实现接口

类与接口的关系为实现关系，即类实现接口。实现的动作类似继承，只是关键字不同，实现使用implements。

其他类(实现类)实现接口后，就相当于声明：”我应该具备这个接口中的功能”。实现类仍然需要重写方法以实现具体的功能。

格式：

　　class 类 implements 接口 {

　　重写接口中方法

　　}　　 

在类实现接口后，该类就会将接口中的抽象方法继承过来，此时该类需要重写该抽象方法，完成具体的逻辑。

• 接口中定义功能，当需要具有该功能时，可以让类实现该接口，只声明了应该具备该方法，是功能的声明。
• 在具体实现类中重写方法，实现功能，是方法的具体实现。

于是，通过以上两个动作将功能的声明与实现便分开了。(此时请重新思考：类是现实事物的描述，接口是功能的集合。)

 

1.4接口中成员的特点

1、接口中可以定义变量，但是变量必须有固定的修饰符修饰，public static final 所以接口中的变量也称之为常量，其值不能改变。后面我们会讲解static与final关键字

2、接口中可以定义方法，方法也有固定的修饰符，public abstract

3、接口不可以创建对象。

4、子类必须覆盖掉接口中所有的抽象方法后，子类才可以实例化。否则子类是一个抽象类。

interface Demo { ///定义一个名称为Demo的接口。

public static final int NUM = 3;// NUM的值不能改变

public abstract void show1();

public abstract void show2();

}

 

//定义子类去覆盖接口中的方法。类与接口之间的关系是 实现。通过 关键字 implements

class DemoImpl implements Demo { //子类实现Demo接口。

//重写接口中的方法。

public void show1(){}

public void show2(){}

}

1.5 接口的多实现

了解了接口的特点后，那么想想为什么要定义接口，使用抽象类描述也没有问题，接口到底有啥用呢？

接口最重要的体现：解决多继承的弊端。将多继承这种机制在java中通过多实现完成了。

 

interface Fu1

{

void show1();

}

interface Fu2

{

void show2();

}

class Zi implements Fu1,Fu2// 多实现。同时实现多个接口。

{

public void show1(){}

public void show2(){}

}

 

怎么解决多继承的弊端呢？

弊端：多继承时，当多个父类中有相同功能时，子类调用会产生不确定性。

其实核心原因就是在于多继承父类中功能有主体，而导致调用运行时，不确定运行哪个主体内容。

为什么多实现能解决了呢？

因为接口中的功能都没有方法体，由子类来明确。

1.6 类继承类同时实现接口

接口和类之间可以通过实现产生关系，同时也学习了类与类之间可以通过继承产生关系。当一个类已经继承了一个父类，它又需要扩展额外的功能，这时接口就派上用场了。

子类通过继承父类扩展功能，通过继承扩展的功能都是子类应该具备的基础功能。如果子类想要继续扩展其他类中的功能呢？这时通过实现接口来完成。

class Fu {

public void show(){}

}

interface Inter {

pulbic abstract void show1();

}

class Zi extends Fu implements Inter {

public void show1() {

}

}

接口的出现避免了单继承的局限性。父类中定义的事物的基本功能。接口中定义的事物的扩展功能。

1.7 接口的多继承

学习类的时候，知道类与类之间可以通过继承产生关系，接口和类之间可以通过实现产生关系，那么接口与接口之间会有什么关系。

多个接口之间可以使用extends进行继承。

interface Fu1{

void show();

}

interface Fu2{

void show1();

}

interface Fu3{

void show2();

}

interface Zi extends Fu1,Fu2,Fu3{

void show3();

}

在开发中如果多个接口中存在相同方法，这时若有个类实现了这些接口，那么就要实现接口中的方法，由于接口中的方法是抽象方法，子类实现后也不会发生调用的不确定性。

1.8 接口的思想

前面学习了接口的代码体现，现在来学习接口的思想，接下里从生活中的例子进行说明。

举例：我们都知道电脑上留有很多个插口，而这些插口可以插入相应的设备，这些设备为什么能插在上面呢？主要原因是这些设备在生产的时候符合了这个插口的使用规则，否则将无法插入接口中，更无法使用。发现这个插口的出现让我们使用更多的设备。

总结：接口在开发中的它好处

1、接口的出现扩展了功能。

2、接口其实就是暴漏出来的规则。

3、接口的出现降低了耦合性，即设备与设备之间实现了解耦。

 

接口的出现方便后期使用和维护，一方是在使用接口（如电脑），一方在实现接口（插在插口上的设备）。例如：笔记本使用这个规则（接口），电脑外围设备实现这个规则（接口）。

 

 

1.9接口和抽象的区别

明白了接口思想和接口的用法后，接口和抽象类的区别是什么呢？接口在生活体现也基本掌握，那在程序中接口是如何体现的呢？

通过实例进行分析和代码演示抽象类和接口的用法。

1、举例：

　　　　犬：

　　　　　　行为：

　　　　　　　　吼叫；

　　　　　　　　吃饭；

　　　　缉毒犬：

　　　　　　　　行为：

　　　　　　　　　　　吼叫；

　　　　　　　　　　　吃饭；

　　　　　　　　　　　缉毒；

 

2、思考：

由于犬分为很多种类，他们吼叫和吃饭的方式不一样，在描述的时候不能具体化，也就是吼叫和吃饭的行为不能明确。当描述行为时，行为的具体动作不能明确，这时，可以将这个行为写为抽象行为，那么这个类也就是抽象类。

可是当缉毒犬有其他额外功能时，而这个功能并不在这个事物的体系中。这时可以让缉毒犬具备犬科自身特点的同时也有其他额外功能，可以将这个额外功能定义接口中。

如下代码演示：

interface 缉毒{

public abstract void 缉毒();

}

//定义犬科的这个提醒的共性功能

abstract class 犬科{

public abstract void 吃饭();

public abstract void 吼叫();

}

// 缉毒犬属于犬科一种，让其继承犬科，获取的犬科的特性，

//由于缉毒犬具有缉毒功能，那么它只要实现缉毒接口即可，这样即保证缉毒犬具备犬科的特性，也拥有了缉毒的功能

class 缉毒犬 extends 犬科 implements 缉毒{

 

public void 缉毒() {

}

void 吃饭() {

}

void 吼叫() {

}

}

class 缉毒猪 implements 缉毒{

public void 缉毒() {

}

}

 

3、通过上面的例子总结接口和抽象类的区别：

相同点:

• 都位于继承的顶端,用于被其他类实现或继承;
• 都不能直接实例化对象;
• 都包含抽象方法,其子类都必须覆写这些抽象方法;

区别:

• 抽象类为部分方法提供实现,避免子类重复实现这些方法,提高代码重用性;接口只能包含抽象方法;
•  一个类只能继承一个直接父类(可能是抽象类),却可以实现多个接口;(接口弥补了Java的单继承)
• 抽象类是这个事物中应该具备的你内容, 继承体系是一种 is..a关系
• 接口是这个事物中的额外内容,继承体系是一种 like..a关系

 

二者的选用:

• 优先选用接口,尽量少用抽象类;
• 需要定义子类的行为,又要为子类提供共性功能时才选用抽象类;

 

标签：

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有