对于 抽象类 接口 的理解
1. 一个子类implements一个接口，如果该子类是非abstract类，就必须实现接口中的所有方法（不管是否需要）；而如果该子类是abstract类
，则可以实现接口的中方法也可以不实现。
一个子类如果是继承一个抽象类，如果该子类是非abstract类，就必须实现基类中的所有抽象方法；而如果该子类是abstract类，则可以实
现基类的中抽象方法也可以不实现。
//这两种情况看起来是一样的，只不过，抽象类中可以有非抽象方法，而接口中必须全是抽象方法。
2. 如果一个接口中定义的方法名改变了，那么所有实现此接口的子类显然将无法通过编译，因为接口的那个改名的方法在非抽象子类中没有实
现。
抽象类如果修改了一个抽象方法的名称，子类同样编译不过，但若修改的是非抽象方法，编译没有问题。
//两者看起来看是差不多的，只不过修改的方法有抽象和非抽象之别。
3. 关于
抽象类如果修改了一个抽象方法的名称，子类同样编译不过，如果修改的是非抽象方法，编译没有问题，这个不确定性恰恰是抽象类的致命
弱点。
--------------------------------
怎么会无法通过呢？初始名为aaa ，子类继承来了aaa的方法，当抽象类的aaa改为bbb后，子类就拥有了aaa，和bbb两个方法
//初始名为aaa（应为抽象方法名），子类继承（并实现）了aaa的方法，当抽象类的aaa改为bbb后，子类就拥有了aaa，和bbb两个方法（子
类这时只是拥有了一个新方法aaa，而抽象类的的抽象方法bbb在子类中没有实现，当然无法编译通过）
----------------------------------------
我发现大家对接口的理解太过片面了，接口可以这样理解：它并不仅仅是一个类，它是一个规范~~~
就象是一个系统，不断有旧的成员被新的成员取代，但系统仍然可以良好运转，为什么？就是因为所以的成员都遵守一个让系统正常运行的规范，在软件中，接口就扮演着这样一个角色，它并没有代替成员做具体的工作（coding）而是告诉成员该如何做(接口中的方法)
再详细一些说就是接口中的方法只定义了参数类型，返回值类型，方法名字，就是告诉成员用什么样的工具（方法名）用什么资源（参数类型）完成什么样的工作（返回值类型）
基于这样的出发点，几个毫不相干的抽象类甚至可以公用一个接口，即接口规范着抽象类
这就是接口最主要的作用，通过接口耦合的系统有更好的整体性和可维护性，可扩展性
-----------------------------------------
但是接口会在无形中至少增加一个类，如果再加上一个抽象隔离的话，就多出来两个。如果其他人也理解这种模式还凑合，如果其他人不理解呢？那就大幅度的增加了类结构图的复杂度（系统初期一般类的数量本来是不多的）。
----------------------------------------
以为使用接口和抽象类会减少代码量就是另外一个误区
一个依赖抽象层的系统在开发过程中，难免会在抽象层和实现层中改来改去，工作量甚至会成倍的增加
这样的系统在后期的维护与再次开发中的好处却是明显的，要做的改动会少很多也会更容易些，很多人都有这样的经验：当为某个程序加上一个功能的时候，突然间发现其他的某个功能不好使了，如果一个抽象层设计良好的系统是不会出现这样的情况的，但这就要取决与设计抽象层之前对可能发生情况的预测是否全面，否则既改接口又改代码无疑是一场噩梦，这是设计者经验多寡的问题。
这些都是我目前对接口的理解，让我具体举一些例子我也举不出来，只可意会不可言传，大家可以记住我说的这些在以后做项目的过程中体会一下
---------------------------------
其实我个人认为，我们在进行OO设计的时候，我们分析得越细致就越提高了我们代码使用的精密性。这时候，我们必须对所有的框架有个详细了解才能开始。这是一种很不好的用户体验。
--------------------------------
大部分新人很难做到理论指导实践的，所以对于新人来说，想用什么就用什么好了。。。保证程序能转就行。等到实践多了，觉得这样写程序开始难受了，自然就会去思考为什么会难受。。如果一直都不觉得难受，也就这样了。。
，则可以实现接口的中方法也可以不实现。
一个子类如果是继承一个抽象类，如果该子类是非abstract类，就必须实现基类中的所有抽象方法；而如果该子类是abstract类，则可以实
现基类的中抽象方法也可以不实现。
//这两种情况看起来是一样的，只不过，抽象类中可以有非抽象方法，而接口中必须全是抽象方法。
2. 如果一个接口中定义的方法名改变了，那么所有实现此接口的子类显然将无法通过编译，因为接口的那个改名的方法在非抽象子类中没有实
现。
抽象类如果修改了一个抽象方法的名称，子类同样编译不过，但若修改的是非抽象方法，编译没有问题。
//两者看起来看是差不多的，只不过修改的方法有抽象和非抽象之别。
3. 关于
抽象类如果修改了一个抽象方法的名称，子类同样编译不过，如果修改的是非抽象方法，编译没有问题，这个不确定性恰恰是抽象类的致命
弱点。
--------------------------------
怎么会无法通过呢？初始名为aaa ，子类继承来了aaa的方法，当抽象类的aaa改为bbb后，子类就拥有了aaa，和bbb两个方法
//初始名为aaa（应为抽象方法名），子类继承（并实现）了aaa的方法，当抽象类的aaa改为bbb后，子类就拥有了aaa，和bbb两个方法（子
类这时只是拥有了一个新方法aaa，而抽象类的的抽象方法bbb在子类中没有实现，当然无法编译通过）
----------------------------------------
我发现大家对接口的理解太过片面了，接口可以这样理解：它并不仅仅是一个类，它是一个规范~~~
就象是一个系统，不断有旧的成员被新的成员取代，但系统仍然可以良好运转，为什么？就是因为所以的成员都遵守一个让系统正常运行的规范，在软件中，接口就扮演着这样一个角色，它并没有代替成员做具体的工作（coding）而是告诉成员该如何做(接口中的方法)
再详细一些说就是接口中的方法只定义了参数类型，返回值类型，方法名字，就是告诉成员用什么样的工具（方法名）用什么资源（参数类型）完成什么样的工作（返回值类型）
基于这样的出发点，几个毫不相干的抽象类甚至可以公用一个接口，即接口规范着抽象类
这就是接口最主要的作用，通过接口耦合的系统有更好的整体性和可维护性，可扩展性
-----------------------------------------
但是接口会在无形中至少增加一个类，如果再加上一个抽象隔离的话，就多出来两个。如果其他人也理解这种模式还凑合，如果其他人不理解呢？那就大幅度的增加了类结构图的复杂度（系统初期一般类的数量本来是不多的）。
----------------------------------------
以为使用接口和抽象类会减少代码量就是另外一个误区
一个依赖抽象层的系统在开发过程中，难免会在抽象层和实现层中改来改去，工作量甚至会成倍的增加
这样的系统在后期的维护与再次开发中的好处却是明显的，要做的改动会少很多也会更容易些，很多人都有这样的经验：当为某个程序加上一个功能的时候，突然间发现其他的某个功能不好使了，如果一个抽象层设计良好的系统是不会出现这样的情况的，但这就要取决与设计抽象层之前对可能发生情况的预测是否全面，否则既改接口又改代码无疑是一场噩梦，这是设计者经验多寡的问题。
这些都是我目前对接口的理解，让我具体举一些例子我也举不出来，只可意会不可言传，大家可以记住我说的这些在以后做项目的过程中体会一下
---------------------------------
其实我个人认为，我们在进行OO设计的时候，我们分析得越细致就越提高了我们代码使用的精密性。这时候，我们必须对所有的框架有个详细了解才能开始。这是一种很不好的用户体验。
--------------------------------
大部分新人很难做到理论指导实践的，所以对于新人来说，想用什么就用什么好了。。。保证程序能转就行。等到实践多了，觉得这样写程序开始难受了，自然就会去思考为什么会难受。。如果一直都不觉得难受，也就这样了。。
