JAVA接口编程的优点

小弟刚工作两年文中所说都是通过自己工作中或做练习总结的经验，当然肯定不是那么准确，有不对之处望和谐指出，因为这个感觉完全是理论所以没有贴一段代码，有兴趣的就看看吧。

项目开发中绝对会碰到接口，但是为什么要使用接口成了绝大多数java程序员的疑问，为什么一定要写个没有实现任何功能的只有几个方名的类，可能也有一些人明白接口就是好，但好在哪里很难解释出来，我当初也是这样想的，但是当我一瞬间觉悟后发现这种想法很幼稚。OOP的四大基本特征 多态 继承 封装 抽象 全与接口有关，可以说不懂接口的人完全不懂OOP是什么，更不用说能做出好项目，所以对接口的理解很重要。讲接口之前再讲一样东西，它与接口是密不可分的，这两者必须要一起讲才行，那就是依赖注入（控制反转）。



spring的核心思想之一，又有人有疑惑了，这东西很麻烦，还要在配置文件中配来配去，直接new一个不是挺好用的吗，多省事啊。
1依赖注入从编程方面讲提高了效率，在系统启动时容器将除去业务逻辑（因为业务不是时时刻刻都会用到的）以外的一大部分方法加载到内存中，一个请求过来时你要哪个方法我从内存中给你哪个方法，而new的时候是需要在内存中分出一点空间来放你new出来的东西，一百个请求new一百次，一亿个请求new一亿次。
2依赖注入从设计模式上来讲提高了解耦性，重用性，与传统的new，一个是给一个是拿（用控制反转来理解这句话）。举例：你要一辆车，自己造一辆（new）。依赖注入像汽车中心（容器）买或者租一辆.自己造要花时间造，汽车场给钱立马给你。如果你就开一次，自己造完了用了一次丢那里浪费了，汽车场租一辆，用完就还回去，别人还能用。可能你又会想，自己造的别人也还能用啊，但那只限于知道你有辆车的人，但只要是人都知道汽车场有汽车。



讲完依赖注入就可以讲接口了。接口的基本特征就不多说了，下面来讲接口到底好在哪



一.目录
开发一个项目中，总是需要互相调用一些功能的，比如业务组开发人员需要技术组提供一些实用的方法，那么就出现了两种情况。
1.不使用接口，直接写。
当你需要去看看这个类有什么你需要的方法时，你看到的是一大堆的代码，悲剧了，几千行代码，有的方法几百行有的方法一两行，哪个是我要的方法呢，一个个找吧，更悲剧者碰上编码习惯不好的，不管是外部方法还是内部封装一下的小方法的修饰名全都用Public,找晕你。
2使用接口
接口没有任何的实现，只有方法名，一排一排很有规则的看下去，我不需要去看他的实现过程，我只需要知道这我想要的达到的目的通过哪个方法能实现，至于他的过程本来就不需要我来考虑。

举例：你买了本hibernate编程思想，你想要知道怎么配置hibernate的参数。翻开一看，蛋疼，没有目录，你就一页一页翻吧，翻的同时还得看清楚点，别翻过头了。



二.变更
开发项目中，不免会有一些大的变更，甚至于上线之后都有可能，那么一些影响全局的变更就出现了。比如数据库本来用的是MySql，变态的需求突然说要换成oracle。
1 没有使用接口开发
写一个新的类，把所有调用的全改掉，因为类型都不对了。
2 使用接口的类
只需要在写一个SQL接口的实现类，在配置文件中修改一下注入的路径，搞定。
有人又会说直接改那个内的方法不就可以了，那我需求再变态一下，白天用MySql晚上用oracle,那是否你所有操作数据库之前都要if(白天)else if(晚上)？，而接口只需要容器支持将注入的实现类换一个就行了，因为实现类必须实现接口的所有抽象方法，所以在编译时是能通过的。

举例：一个医院有一个口腔部门，口腔部门里有一位医生叫王医生，通过写死的看法我如果要去看病就是找这个王医生，一天王医生不干了，来了一个刘医生，完了我只能看王医生的，这可能吗

？通过接口来看医院是接口他能治病，口腔部门是医院的子类，明确到了是治疗口腔的，医生是实现类，他能治口腔病，至于这个医生叫什么，关我屁事，我只要知道你有治病这个方法就行了。

三.扩展性
最近工作太轻松，闲来无聊做了个练习小项目，这个项目除了必要的DOM4J和JDBC没用一个jar包，前言说完了，说说我的做法。项目启动时先加载自己做的容器，然后加载DB、Log等接口、最后加载service、action，刚开始我在加载容器后就直接按顺序把DB配置文件加载好生成一个DBService丢到数据总线中，然后加载LOG同样的做法。考虑了很久发现这种做法有点问题，后来改成这样了，容器无非就是管理接口类的东西，我就又写了个抽象类（因为抽象类可以有成员变量）一个抽象方法initService 两个成员变量 HashMap serviceMap
HashMap serviceDataMap  一个存service 一个存它可能会附带的一些数据，我现在只需要写实现类 在initService 方法中加载XML 将该Service初始化好 丢到serviceMap中就哦了，这样做的好处就是，无论我以后有多少插件配置文件配一个实现类，写一个实现类，方法中加载一些东西，丢到父类的serviceMap中，以后所有的类注入都能注入该service。

四.结构化
一个项目的好坏就要看他的结构是否清晰，java规定了类只能单一继承，是为了避免错综复杂的关系，在很多文章中都提到过类的继承是项目中的一颗地雷，而接口没有实现过程，只有表明是干什么的，所以就算多继承(接口可以继承多个接口)，结构还是很清晰的。


自我总结出就这四个优点很明显，看别人的文章说的最多的还有一个好处开发中使用，我觉得很恶心，实现屁没写方法一大堆，写完一大堆的方法后，去写实现时突然发现又要加个新方法才行或者写好的那个方法又没啥用，要删掉，最后搞的你心思无限宽广，有时候开发过程想太多太远是没好处的，可能写的过程中又会出现很多其他的想法，因为我们是人，不是CPU，运行的不是那么准确，当然几乎每个架构师技术都很牛X，估计也是有人能做到这一点的，但是做不到的还是慢慢来，都写好了再弄个接口或抽象类。



最后总结一点  接口就是你需要什么就调什么  完完全全的封装 不用考虑你的实现过程 连类名都可以忽略 你只要告诉容器  我需要的是哪种类型的接口就行了






评论

15 楼 kfc_davy 2012-06-19  

liguocai2009 写道

问下楼主，如果有一个接口，已经被1000个子类实现。现在需要新增一个方法，950个类需要实现并且实现是一致的。如何解决这个问题？
如果那1000个子类是继承抽象类的，那么就很好解决了。。。

首先可以看看从组合上能否规避掉，非加不可，那就只有extends了，

但是反过来说，如果一个interface有1000个实现的话，那么多数在20-50之间就会重构出一个abstract来，不然太恐怖了，就像一个高楼没有地基一样。哈哈。个人看法

14 楼 liguocai2009 2012-06-19  

Mybeautiful 写道

liguocai2009 写道

Mybeautiful 写道

liguocai2009 写道

问下楼主，如果有一个接口，已经被1000个子类实现。现在需要新增一个方法，950个类需要实现并且实现是一致的。如何解决这个问题？
如果那1000个子类是继承抽象类的，那么就很好解决了。。。

呵呵，这个问题是有点极端，可以用变通的办法解决。

1. 增加一个抽象类A，只实现这个新增的方法；然后让950个类增加一个extents  A.
2. 另外50个由于不一样，可以继承直接实现A均可，反正它们是要实现这个新方法的。

当你碰到这个问题时，你确实会考虑包含一些继承的关系，会更具灵活性；但这并不代表最先1000个类仅仅实现一个接口是不好的；（实际上，你的实现类也不是一下就到1000个的，当你加到10个时，你或许就已经发现某些类需要共同的方法，这时候你就已经改进了设计去兼容将来可能出现的类似问题） 世易时移，故不断重构是需要的。

我就遇到过这个问题，数量没有1000个，有200多个吧，开发人员不愿意一个一个去改，他们期望有一个简单的方法去处理这个扩展的问题。

现在想想java的collection类库，
public class ArrayList<E> extends AbstractList<E>,implements List<E>,...
为什么ArrayList既要实现接口又要继承抽象类，可能是因为方便增加方法吧。。。

我跟你提供的方法就是 实现接口，又扩展一个类啊 （这个类也实现这个接口。）

1. 增加一个抽象类A，只实现这个新增的方法；然后让950个类增加一个extents  A.

我明白你的意思。
之前没有加上extends A，现在往每个类上面extends A真的会比较麻烦哦。。。虽然现在我们就这么做的。不知道有没有更好的方式来增加接口的方法...

13 楼 Mybeautiful 2012-06-19  

liguocai2009 写道

Mybeautiful 写道

liguocai2009 写道

问下楼主，如果有一个接口，已经被1000个子类实现。现在需要新增一个方法，950个类需要实现并且实现是一致的。如何解决这个问题？
如果那1000个子类是继承抽象类的，那么就很好解决了。。。

呵呵，这个问题是有点极端，可以用变通的办法解决。

1. 增加一个抽象类A，只实现这个新增的方法；然后让950个类增加一个extents  A.
2. 另外50个由于不一样，可以继承直接实现A均可，反正它们是要实现这个新方法的。

当你碰到这个问题时，你确实会考虑包含一些继承的关系，会更具灵活性；但这并不代表最先1000个类仅仅实现一个接口是不好的；（实际上，你的实现类也不是一下就到1000个的，当你加到10个时，你或许就已经发现某些类需要共同的方法，这时候你就已经改进了设计去兼容将来可能出现的类似问题） 世易时移，故不断重构是需要的。

我就遇到过这个问题，数量没有1000个，有200多个吧，开发人员不愿意一个一个去改，他们期望有一个简单的方法去处理这个扩展的问题。

现在想想java的collection类库，
public class ArrayList<E> extends AbstractList<E>,implements List<E>,...
为什么ArrayList既要实现接口又要继承抽象类，可能是因为方便增加方法吧。。。

我跟你提供的方法就是 实现接口，又扩展一个类啊 （这个类也实现这个接口。）

12 楼 liguocai2009 2012-06-19  

Mybeautiful 写道

liguocai2009 写道

问下楼主，如果有一个接口，已经被1000个子类实现。现在需要新增一个方法，950个类需要实现并且实现是一致的。如何解决这个问题？
如果那1000个子类是继承抽象类的，那么就很好解决了。。。

呵呵，这个问题是有点极端，可以用变通的办法解决。

1. 增加一个抽象类A，只实现这个新增的方法；然后让950个类增加一个extents  A.
2. 另外50个由于不一样，可以继承直接实现A均可，反正它们是要实现这个新方法的。

当你碰到这个问题时，你确实会考虑包含一些继承的关系，会更具灵活性；但这并不代表最先1000个类仅仅实现一个接口是不好的；（实际上，你的实现类也不是一下就到1000个的，当你加到10个时，你或许就已经发现某些类需要共同的方法，这时候你就已经改进了设计去兼容将来可能出现的类似问题） 世易时移，故不断重构是需要的。

我就遇到过这个问题，数量没有1000个，有200多个吧，开发人员不愿意一个一个去改，他们期望有一个简单的方法去处理这个扩展的问题。

现在想想java的collection类库，
public class ArrayList<E> extends AbstractList<E>,implements List<E>,...
为什么ArrayList既要实现接口又要继承抽象类，可能是因为方便增加方法吧。。。

11 楼 Mybeautiful 2012-06-19  

liguocai2009 写道

问下楼主，如果有一个接口，已经被1000个子类实现。现在需要新增一个方法，950个类需要实现并且实现是一致的。如何解决这个问题？
如果那1000个子类是继承抽象类的，那么就很好解决了。。。

呵呵，这个问题是有点极端，可以用变通的办法解决。

1. 增加一个抽象类A，只实现这个新增的方法；然后让950个类增加一个extents  A.
2. 另外50个由于不一样，可以继承直接实现A均可，反正它们是要实现这个新方法的。

当你碰到这个问题时，你确实会考虑包含一些继承的关系，会更具灵活性；但这并不代表最先1000个类仅仅实现一个接口是不好的；（实际上，你的实现类也不是一下就到1000个的，当你加到10个时，你或许就已经发现某些类需要共同的方法，这时候你就已经改进了设计去兼容将来可能出现的类似问题） 世易时移，故不断重构是需要的。

10 楼 liguocai2009 2012-06-19  

问下楼主，如果有一个接口，已经被1000个子类实现。现在需要新增一个方法，950个类需要实现并且实现是一致的。如何解决这个问题？
如果那1000个子类是继承抽象类的，那么就很好解决了。。。

9 楼 332337246 2012-06-18  

通俗易懂，总结的太好了

8 楼 sfwhhp 2012-06-18  

文笔流畅，表述清晰。学习了

7 楼 sfwhhp 2012-06-18  

文笔流程，表述清晰。学习了。

6 楼 yell_dragon 2012-06-18  

有想法，赞同！

5 楼 kfc_davy 2012-06-18  

我就觉得接口的用处
1.OO 面向对象，不暴露不该暴露的
2.模块间解耦
3.可以让多个码农同时工作

所以在项目启动时接口和数据模型是最先定义的也是最重要的，

4 楼 hehebaiy 2012-06-18  

写的很有见解，学习了！！

3 楼 jinbingchuan 2012-06-18  

2 楼 cywhoyi 2012-06-18  

两年比我了解的深刻，在我印象中接口就是一种定义、实现一机面向协议编程

1 楼 Mybeautiful 2012-06-18  

总结的很好。不过Spring的依赖注入跟效率没有关系，你可能说的是它的“工厂特性”， 依赖注入就是为了解耦，让模块彼此都不直接依赖，而是都依赖于Spring容器。