
2

3

4

5

6

7

8

9

10

11

12

13

14

15

16


2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

同样是抽象类,但修改后的类,就不再是纯抽象类了。纯抽象的类,我们要求是没有构造函数,没有任何的非抽象成员,所有成员的访问修饰都是public的,这样我们有了一个新的名词:接口interface。
现了解一下接口的定义要求
接口就是一个纯抽象类(所以接口是引用类型),接口可以包含方法、属性、事件和索引器,实现该接口的类或结构必须实现这些成员。
相比起抽象类,接口有以下特征
不需要声明接口为抽象或虚拟(本来就是)
接口不允许有构造函数(纯抽象了,根本不需要构造)
接口不允许有析构函数(本来无构造,何需有析构)
接口的所有成员都是抽象的(纯抽象类嘛)
接口只可以从接口继承(因为只有接口可以保证使纯虚的,如果从抽象类继承,不能保证抽象类中可能存在非抽象的成员)
接口成员不允许有任何修饰(默认就是public的,也只有是public的)
一个类或结构可以实现多个接口
那为什么要接口呢?
我们设想一个场景,假设我要写一个模拟角色的游戏,每个玩家都可以拥有多个角色(职业),如果有一个人其职业是医生,但同时他也是研究生,在学校带课,但又在攻读博士,同时呢,由于工作出色,担任了科室主任,在回家的路上又去了超市。
那我们可以观察到,这个人实现了的角色有:医生、学生、讲师、领导、顾客。那类怎么描述实现呢?用继承?

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

如果你还有一点点面向对象的理智的话,就知道这个非常非常的错误的设计。不但类的结构非常的臃肿,还难以代码重用。
所以我们将代码改为使用接口来实现。
我们把job角色定义为接口,而不是类

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

这样Person 类就可以实现(继承)多个接口

2

3

4

5

6

7

8

21

22

34

35

42

43

44

45

58

注意,IConsumer 成员采用的是显式实现。
标准实现的模型是:public 接口成员[返回值 名字 参数] {}
显式实现的模型是:没有访问修饰符 接口名称.接口成员[返回值 名字 参数] {}
显式实现的接口成员没有访问修饰符,也就意味着显式实现的成员感觉上是私有的,不能被访问。那这样的实现有什么意思呢?
请看下篇:我,只关心接口。