究竟要不要接口？

解释一下，为什么需要接口而不直接实现类。

    在这个帖子里讨论了关于接口的使用，有一句话总结的很好：接口是定义行为规约的，抽象类是提供公共行为的，具体类是实现具体行为的。但定义归定义，在实际开发中，应该怎么用接口呢？目前主流技术中的接口是否过度使用？这些问题也许只有大牛（有极其多的项目经验）才能回答吧，俺等小子就不发表什么观点了，做做总结提高提高就行了。

    帖子中大多数是强烈支持面向接口编程的，但能看出大部分都是跟风，基本上都没有什么论据来支持这个观点，有的也就是从书上找到的解释接口的好处，但它给项目本身带来多少好处，基本上没人说上来，比如有人说接口可以实现多态，听上去很对，可实际项目又有多少会用到多态，不怕大家笑话，到现在我还没在项目中真正运用过多态，大多数情况下一个接口就是对应一个实现类，感觉就是为了接口而接口，本来这个帖子也没什么新意了，但由于axeon的横空出世，使得这个帖子有一些看点，最后边robbin老大也现身了，不过看来讨论的最后也就不了了之了，关于这个问题本来没有一个标准，从来是一个用来打口水仗的好题目，

       Axeon认为大多数情况下，接口无端的增加了代码的复杂性，并且在大多数情况下接口没起到它应该起的作用，或者说是我们一厢情意地认为用接口可以带来移植性、扩展性，可直到这个项目（产品）寿终正寝时，这些特性还没用到过。这就是我们一边叫嚣着要面向接口编程，一边又怀疑这么做有什么用的原因吧。在这个帖子里有一点说有很多，单元测试需要接口，只有面向接口编程才能很方便地进行单元测试。

       Axeon在帖子中说：任何一门技术，从最基础的经济学角度来说，都要满足多快好省的要求，才能不被淘汰，才能够淘汰别人。那么什么是多块好省呢？我的理解是要能够快速开发，运行还要高效。如果从这个观点来评判，我想思路会更加清晰的。如果从这个角度来说，接口的害好像大于利，应该摈弃，但为什么面向接口又这个流行呢，我想一定有它的道理吧！

只是俺愚钝，不明其义吧了，

       大段引用一下axeon的话

“新技术的特性必然要有需求与此对应，否则这个新特性就是屠龙术，仅仅有可吹嘘的本钱。另外，这个需求首先应该是业务需求，而不是解决自身问题的。因为技术最终是为业务服务的，通过业务来体现技术价值

从多快好省的角度上来说，java当前所谓框架的代表ssh，引导的是一个开发慢，运行慢的技术派系，他的所谓维护性和扩展性（或许）优势是不明确的，甚至是不存在的。开发效率和运行效率是最大的软肋。

为什么要接口？除了隐藏实现，那么就是多态。如果使用spring，有什么好隐藏的？更因为编译器就绑定实现了，怎么玩多态？如果为了庞大而好看，我建议你一个类里只写一个方法好了！

为什么要继承？而不用调用？相比较继承，调用是更清晰的关系，除非是必要继承，没事儿你继承什么？

更不说大把人用的spring的beanFactory，更是笑死人了！这也是spring对他来说最重要的用处。首先如果只用单例，我干嘛不在类和方法上加上static？从实际使用上来说，spring通过hashmap来查找实例，而static是从内存直接调用，哪个更简单，效率更好，甚至零配置？

至于分层，更是笑话！曾经有一个帖子，抱怨招聘了一个技术高手，过来之后就会分层。结果招致群攻，简直笑死我了。我回了一个帖子，说了一句按需分层，竟然被评差贴。

一个项目的技术水平根本就不可以用是否使用ssh，是否分层来进行判断。更不说大把分层的代码里面仅仅是对上层的调用，但是如果程序需要改动，分层越多越难改，便于维护压根就是一个说辞。”

       可以看的出axeon是从实战出发的，姑且不说他的观点对不对，但至少很实在，是自己在做项目中的一些体验，比那些动动就空谈这个技术好，那个技术坏的的人强多了，但我想开发不能只追求多快好省，维护才是最重要的，用ssh的好处之一就是它将来便于维护（当然前提是你会用ssh）

       这个问题很大。。。。。。。。。。。。。continuing