对于 抽象类 接口 的理解

1. 一个子类implements一个接口,如果该子类是非abstract类,就必须实现接口中的所有方法(不管是否需要);而如果该子类是abstract类

,则可以实现接口的中方法也可以不实现。
   一个子类如果是继承一个抽象类,如果该子类是非abstract类,就必须实现基类中的所有抽象方法;而如果该子类是abstract类,则可以实

现基类的中抽象方法也可以不实现。
   //这两种情况看起来是一样的,只不过,抽象类中可以有非抽象方法,而接口中必须全是抽象方法。

2. 如果一个接口中定义的方法名改变了,那么所有实现此接口的子类显然将无法通过编译,因为接口的那个改名的方法在非抽象子类中没有实

现。
   抽象类如果修改了一个抽象方法的名称,子类同样编译不过,但若修改的是非抽象方法,编译没有问题。
   //两者看起来看是差不多的,只不过修改的方法有抽象和非抽象之别。

3. 关于
   抽象类如果修改了一个抽象方法的名称,子类同样编译不过,如果修改的是非抽象方法,编译没有问题,这个不确定性恰恰是抽象类的致命

弱点。

--------------------------------

   怎么会无法通过呢?初始名为aaa ,子类继承来了aaa的方法,当抽象类的aaa改为bbb后,子类就拥有了aaa,和bbb两个方法

   //初始名为aaa(应为抽象方法名),子类继承(并实现)了aaa的方法,当抽象类的aaa改为bbb后,子类就拥有了aaa,和bbb两个方法(子

类这时只是拥有了一个新方法aaa,而抽象类的的抽象方法bbb在子类中没有实现,当然无法编译通过)
----------------------------------------
我发现大家对接口的理解太过片面了,接口可以这样理解:它并不仅仅是一个类,它是一个规范~~~

就象是一个系统,不断有旧的成员被新的成员取代,但系统仍然可以良好运转,为什么?就是因为所以的成员都遵守一个让系统正常运行的规范,在软件中,接口就扮演着这样一个角色,它并没有代替成员做具体的工作(coding)而是告诉成员该如何做(接口中的方法)

再详细一些说就是接口中的方法只定义了参数类型,返回值类型,方法名字,就是告诉成员用什么样的工具(方法名)用什么资源(参数类型)完成什么样的工作(返回值类型)

基于这样的出发点,几个毫不相干的抽象类甚至可以公用一个接口,即接口规范着抽象类

这就是接口最主要的作用,通过接口耦合的系统有更好的整体性和可维护性,可扩展性
-----------------------------------------
但是接口会在无形中至少增加一个类,如果再加上一个抽象隔离的话,就多出来两个。如果其他人也理解这种模式还凑合,如果其他人不理解呢?那就大幅度的增加了类结构图的复杂度(系统初期一般类的数量本来是不多的)。
----------------------------------------
以为使用接口和抽象类会减少代码量就是另外一个误区

一个依赖抽象层的系统在开发过程中,难免会在抽象层和实现层中改来改去,工作量甚至会成倍的增加
这样的系统在后期的维护与再次开发中的好处却是明显的,要做的改动会少很多也会更容易些,很多人都有这样的经验:当为某个程序加上一个功能的时候,突然间发现其他的某个功能不好使了,如果一个抽象层设计良好的系统是不会出现这样的情况的,但这就要取决与设计抽象层之前对可能发生情况的预测是否全面,否则既改接口又改代码无疑是一场噩梦,这是设计者经验多寡的问题。

这些都是我目前对接口的理解,让我具体举一些例子我也举不出来,只可意会不可言传,大家可以记住我说的这些在以后做项目的过程中体会一下
---------------------------------
其实我个人认为,我们在进行OO设计的时候,我们分析得越细致就越提高了我们代码使用的精密性。这时候,我们必须对所有的框架有个详细了解才能开始。这是一种很不好的用户体验。
--------------------------------
大部分新人很难做到理论指导实践的,所以对于新人来说,想用什么就用什么好了。。。保证程序能转就行。等到实践多了,觉得这样写程序开始难受了,自然就会去思考为什么会难受。。如果一直都不觉得难受,也就这样了。。
posted @ 2008-01-11 17:30  蝗虫的大腿  阅读(608)  评论(0编辑  收藏  举报