java--------抽象类与接口的区别
1、抽象类与接口的抽象层次是不同的
抽象类是对类抽象,接口是对行为抽象。类包含了属性与行为,所以说接口是更具体的抽象。
2、抽象类与接口的设计层次是不同的
抽象类是一种自下而上的设计,先有子类才能提取公同的属性与行为,抽象出父类,意思讲:子类的共同属性抽象出来的类就是父类,抽象类主要是规定/定义一个族群的祖先;
接口是一种自上而下的设计,先规定行为方法,只要可以实现这些行为,就可以成为接口的实现类,因为inteface具有多继承性。
3、抽象类与其派生类的关系和接口与其实现类的关系本质是不同的
抽象类与其派生类是一种“is-a”关系,即父类和派生子类在概念上的本质是相同的(父子关系,血缘联系,很亲密)。
接口与其实现类是一种“like-a”关系,即接口与实现类的关系只是实现了定义的行为,并无本质上的联系(契约关系,很淡漠的利益关系)。
举个例子:比如说一个动物抽象类,定义了跑的方法、叫的方法,但如果一个汽车类可以实现跑、可以实现叫,它就可以继承动物抽象类吗?!这太不合理了,汽车不是动物呀!而如果通过接口定义跑的方法、叫的方法,汽车类作为实现类实现跑和叫,完全OK很合理,就因为没有继承关系的约束。
为了更好的阐述他们之间的区别,下面将使用一个很棒的例子来说明。该例子引自博文链接。
我们有一个Door的抽象概念,它具备两个行为open()和close(),此时我们可以定义通过抽象类和接口来定义这个抽象概念:
抽象类:
abstract class Door{
abstract void open();
abstract void close();
}
- 1
- 2
- 3
- 4
- 1
- 2
- 3
- 4
接口:
interface Door{
void open();
void close();
}
- 1
- 2
- 3
- 4
- 1
- 2
- 3
- 4
至于其他的派生类可以通过:
1、使用extends使用抽象类方式定义Door
2、使用implements接口方式定义Door
这里发现两者并没有什么很大的差异,但是现在如果我们需要门具有报警的功能,那么该如何实现呢?
解决方案一:给Door增加一个报警方法:alarm();
abstract class Door{
abstract void open();
abstract void close();
abstract void alarm();
}
- 1
- 2
- 3
- 4
- 5
- 1
- 2
- 3
- 4
- 5
或者
interface Door{
void open();
void close();
void alarm();
}
- 1
- 2
- 3
- 4
- 5
- 1
- 2
- 3
- 4
- 5
这种方法违反了面向对象设计中的一个核心原则 ISP (Interface Segregation Principle)—见批注,在Door的定义中把Door概念本身固有的行为方法和另外一个概念”报警器”的行为方法混在了一起(意思就是说:Door(抽象类)的属性是所有门的共同特性,而具有报警器属性的门只有报警门所具有,如果把报警特性放到Door中,假设要定义一个不报警的门就需要修改Door,但是报警门又extends Door,所以这一改就会牵动很多其他的类,因此面向对象设计中有一个核心原则ISP)。这样引起的一个问题是那些仅仅依赖于Door这个概念的模块会因为”报警器”这个概念的改变而改变,反之依然。
解决方案二:
既然open()、close()和alarm()属于两个不同的概念,那么我们依据ISP原则将它们分开定义在两个代表两个不同概念的抽象类里面,定义的方式有三种:
1、两个都使用抽象类来定义。
2、两个都使用接口来定义。
3、一个使用抽象类定义,一个是用接口定义。
由于java不支持多继承所以第一种是不可行的。后面两种都是可行的,但是选择何种就反映了你对问题域本质的理解。
如果选择第二种都是接口来定义,那么就反映了两个问题:
1、我们可能没有理解清楚问题域,AlarmDoor在概念本质上到底是门还报警器。
2、如果我们对问题域的理解没有问题,比如我们在分析时确定了AlarmDoor在本质上概念是一致的,那么我们在设计时就没有正确的反映出我们的设计意图。因为你使用了两个接口来进行定义,他们概念的定义并不能够反映上述含义。
第三种,如果我们对问题域的理解是这样的:AlarmDoor本质上Door,但同时它也拥有报警的行为功能,这个时候我们使用第三种方案恰好可以阐述我们的设计意图。AlarmDoor本质是们,所以对于这个概念我们使用抽象类来定义,同时AlarmDoor具备报警功能,说明它能够完成报警概念中定义的行为功能,所以alarm可以使用接口来进行定义。如下:
abstract class Door{
abstract void open();
abstract void close();
}
interface Alarm{
void alarm();
}
class AlarmDoor extends Door implements Alarm{
void open(){}
void close(){}
void alarm(){}
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
这种实现方式基本上能够明确的反映出我们对于问题领域的理解,正确的揭示我们的设计意图。其实抽象类表示的是”is-a”关系,接口表示的是”like-a”关系,大家在选择时可以作为一个依据,当然这是建立在对问题领域的理解上的,比如:如果我们认为AlarmDoor在概念本质上是报警器,同时又具有Door的功能,那么上述的定义方式就要反过来了。
批注: ISP(Interface Segregation Principle):面向对象的一个核心原则。它表明使用多个专门的接口比使用单一的总接口要好。
一个类对另外一个类的依赖性应当是建立在最小的接口上的。
一个接口代表一个角色,不应当将不同的角色都交给一个接口。没有关系的接口合并在一起,形成一个臃肿的大接口,这是对角色和接口的污染