有关接口和抽象类的问题

1. 一个子类如果implements一个接口，就必须实现接口中的所有方法（不管是否需要）；如果是继承一个抽象类，只需要实现需要的方法即可，这是抽象类的一个优点

2. 如果一个接口中定义的方法名改变了，那么所有实现此接口的子类显然将无法通过编译，因为它们所实现的方法名已经不存在了，这是接口的一个缺点；而抽象类就不存在这个问题，只是为子类添加了一个新的方法（接口中旧的方法）

3. 看前面两点，似乎抽象类要比接口有着更多的优点，但它却有着一个难以弥补的缺点：就是一个子类只能有一个父类。A extends B . 这样A就拥有了B的所有方法和功能，但当A还想拥有C的功能的时候。就不能通过 A extends C 来实现，   而需要走一些弯路。目前系统架构的趋势就是由针对抽象（借口，抽象类）而不是具体编程，并且将功能尽可能的细分。   这就需要通过实现多个接口的方式来实现，显然，抽象类无法提供这样的功能。从系统重构的角度来说，一个具体类抽象出接口是十分方便的。只需要写一个接口，里面定义具体类的所有方法，然后在为这个具体类implement这个接口就可以了。而抽象类就要复杂的多，比如说 B extends A , C extends B 如果想要为c抽象出一个抽象类D的话，就需要找到它的最顶层A来从头做起,因为无法做到C extends D
-------------------------------
继承抽象类的时候不需要实现全部方法，但此子类还是abstract的，无法实例化
-------------------------------
我的意思也是尽量使用interface，但抽象类也不是说没用，应该是各有各的优点。最好的方法就是写一个接口，然后做一个这个接口的default抽象类实现，根据需要选择实现接口还是继承抽象类，但这样的缺点就是写太多的类
-------------------------------
抽象类的优点：B继承A，C也继承A，假设类B、C中继承的fun1这个方法实现代码是一样的，则可以在A中写好代码，BC只要调用父类A的方法既可，不用重新编写代码；而其他BC方法名相同、具体实现不相同的代码，则在A写成抽象的方法。
-------------------------------
这句话讲的很好，以此类推，不断的extends出新的抽象类，不断完成新的方法，以供不同的类来继承实现，提高代码的复用性，但缺点是过于死板，针对性强了一些
-------------------------------
要想实现接口隔离只能通过接口来实现，这也是abstract的最大缺陷
-------------------------------
接口可多继承，地球人都知道，接口里的东东是public的。
-------------------------------
整理一下楼主的贴：

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

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

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

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

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

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

弱点。

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

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

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

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

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

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

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

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

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

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