接口和继承的区别

当使用继承的时候,主要是为了不必重新开发,并且在不必了解实现细节的情况下拥有了父类我所需要的特征。

但是很多时候,一个子类并不需要父类的所有特征,它可能只是需要其中的某些特征,但是由于通过继承,父类所有的特征都有了,需要的和不需要的特征同时具备了。而那些子类实际上不需要用到的,有时候甚至是极力避免使用的特征也可以随便使用,这就是继承的副作用。特别是允许多重继承的OO语言中,很容易引起不容易发现的错误。所以在OO的语言中,会创造出各种规定来限制子类使用父类中的某些方法。

就拿你举的例子来说,如果狗的主人只是希望狗能爬比较低的树,但是不希望它尾巴可以倒挂在树上,像猴子那样可以飞檐走壁,以免主人管不住它。那么狗的主人肯定不会要一只猴子继承的狗。

设计模式更多的强调面向接口。猴子有两个接口,一个是爬树,一个是尾巴倒挂。我现在只需要我的狗爬树,但是不要它尾巴倒挂,那么我只要我的狗实现爬树的接口就行了。同时不会带来像继承猴子来带来的尾巴倒挂的副作用。这就是接口的好处。

OO技术发展也有好多年了,一个很明显的趋势就是继承的使用越来越少,而接口的使用越来越广泛了。其实只要稍微比较一下JDK里面那些最早就有的类库和最近才加进去的类库,就可以很明显的感觉到OO技术领域的编程风格的变迁,由大量的继承到几乎无处不用的面向接口编程。

呵呵,接口不是替代继承。比如说我现在就是要我的动物去爬树,我根本就不需要知道到底是狗去爬树还是猴子去爬树。我派一个“能爬树”的动物去爬。这个能爬树的动物既可以是猴子,也可以是狗。这样不是很灵活吗?

狗(爬树,咬人)
猴子(爬树,尾巴倒挂)

如果我只要满足爬树的要求,我根本就不管它是不是狗。

如果我既要爬树也要咬人,那么我当然可以选狗,也可以创建一个接口(爬树咬人),然后让狗实现(爬树咬人)接口。

因为我要的是实现我的软件的功能,只要实现了我需求的功能,我管它是不是狗呢?也许狗可以,也许狗不可以,也许狗今天可以,以后又不可以了。我都不管。我只要(爬树咬人)接口。

也许我原来一直用狗来完成我的爬树咬人接口,但是后来我发现另一种动物,比如猫吧,在爬树咬人这个功能上比狗更灵活,于是我就用猫替换了狗,而且代码一点都不需要修改。 
阅读更多

没有更多推荐了,返回首页