问题描述
- 关于接口的理解，还有哪些不足的地方。。
-
- 是这样，楼主本人刚学Java的时候，看到抽象类与接口，感觉很不理解，时常为两者的业务场景纠缠不清.
- 后来在网上百度，七嘴八舌，要么只是说一些语法上的不同，要么就是提一些不痛不痒的例子，比如什么学生类，老师类实现人的某项功能balabala...
- 其实我个人觉得刚开始还是从代码层面上说话更能让人理解。
- 关于抽象类，在实际应用中我更喜欢把它当做“模板”来使用，抽象类的好处就是，一半事情，父类替你做了，OK，子类直接调取；另一半事情留给子类自己去实现，相比较于接口，它的子类不太适合作为一个参数进行传递。
- 关于接口，什么称呼都有。。。
- 我个人理解的接口是这样：
- 提高某个数据类更“灵活”，如果把抽象类的继承关系比作垂直，那么接口就相当于把这个数据类型在水平方向进行延展；
- 可以直接使用此匿名实例，或者用句柄接收此实例作为参数进入方法栈；
- 使某个两或者多个个平行关系的实现类产生关联;
- 解耦，这意味着啥，通过接口，可以减少重复代码，越是越大的项目越是能体现出接口的威力。
- 关于接口的嵌套，这个情况有，但是不多，楼主也只是在为数不多项目里发现过一次。
- 抽象类与接口各有各的好处，反正没啥不能new的，还是看需求走向，与业务原则。
- 最后楼主可能在某些点说的不是很完全，请大家多多指教，献丑了。。。
解决方案
个人觉得楼主对于抽象类的理解是比较准确的。抽象类其实并不是一种“抽象”（有点绕嘴），而更类似一种“公共实现”。因此在面向对象设计中，抽象类的重要性比不上接口。个人觉得抽象类更类似于一种实现细节。
而接口这是真正的“抽象”。将一组相关的属性/操作提取出来供调用者使用。从而使得调用者和实现者解耦。
实际工作中经常出现的情况是，调用者C（已存在），需要执行功能A；实现者O，支持功能A，但是还做了一大堆其他事情。这时候吧功能A提取出来，做个接口，然后让C通过接口A调用O，这样需要换个P来实现A功能的时候就可以直接换掉O，而不用再修改C了。
解决方案二：
很简单，价值观不同。网上你看到大多数人其实都是码畜，这些人仅限于完成任务，编写粗制滥造的程序，这种价值观决定了他们的思维，用什么东西能做什么不能做什么。
回应这些低端代码工最简单的办法就是告诉他们，从一种编程语言中拿走接口、抽象类等语法特性，这种语言所能做的事情一件也不会少——只要它仍然是图灵等价的，那么它就能完成一切编程任务。
还有一些是学生党，这些人毫无编程经验，专门捣鼓一些似是而非的术语和所谓的“心得”，这些“心得”好一些的是他们自己在几次调试中观察了一些现象后胡思乱想出来的，糟糕一点的是以讹传讹或者胡编乱造。总之他们的出发点和落脚点都和编程无关。
你知道你被这些人打败的原因是在他们的价值观和世界里的法则根本和我们不同。比如说他们会从没有接口如何如何去讨论接口的用处。或者从JRE实现接口和实现继承类的手段有什么不同来比较两者。你和他们讨论你就输了。
好比你拥有了汽车，你去和一个买不起汽车的穷人讨论汽车有什么用。他会告诉你汽车能办到的事情他走路都能办到，或者汽车多么费油还会出交通事故一样。
解决方案三：
去看设计模式把 推荐《Head First设计模式》