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

也许大家都不觉得这是个问题，为什么呢？有的人认为用接口是理所当然的，无需置疑的，有的人，比如我，就觉得这根本就是多余。

从观点上，这是学院派和实战派的区别，这是好听的话。

为什么出现这种现象，我想还是技术背景的问题。

第一个是时间界限：凡是02以后做java的，普遍都能接受类似struts,spring,hibernate之类的框架，02年之前做java的，接受并且使用这些框架是有些困难的。这是一个先入为主的问题，上来就用所谓ssh这些框架，哪里有时间和机会来思考和质疑呢？
第二个是语言界限：语言背景越是单一的，特别是只做过java的，越是对ssh深信不疑，以致崇拜。语言背景越是复杂的，比如做过c,delphi,php,.net,ruby的，越容易对ssh产生怀疑感。

任何一门技术，从最基础的经济学角度来说，都要满足多快好省的要求，才能不被淘汰，才能够淘汰别人。那么什么是多块好省呢？我的理解是要能够快速开发，运行还要高效。如果从这个观点来评判，我想思路会更加清晰的。

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

首先肯定一点，JAVA本身并没有错，它仅仅是一门语言而已。

和同时期，早期一些，晚期一些的语言相比，java现在成绩如何呢？我想可以通过sourceforge上的开源项目数量来评判。如果从项目数量来看，我想php>perl>java吧？没准过几年ruby超越java也不是不可能。

有人说java的市场在企业级开发上，点点市面上的产品，又有多少家是抱着ssh开发的呢？

java这几年的失败，一方面是sun的问题，一方面也许就是定位所谓的企业级，还有一方面就是社团的注意力过多的关注在所谓的架构上，而不是产品应用上。

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

为什么会有“忽悠”，就是因为偷懒，不经大脑思考，就就跟风呼叫的人太多了，这误导了下一批人，因为众口铄金，皇帝的新衣面前，还有几人敢于说话？

技术浪潮总是几年来一次，大浪淘沙。有人站在最前面得利了，但是最傻的是后面跟着抬轿子的。所有的技术革新，你必须有先知先觉。

javaeye是怎么起来的？是因为ejb，一直到现在还有为ejb呼喊的jdon，当然，这个jdon还被好多人笑话过呢。我想当年ejb火的时候，你们肯定也像义和团一样保卫ejb。因为有的人压根就不用脑子思考，搞不清自己的站位，就连吵架，也是看哪边人多，就站在哪边的。

当然spring确实解决了一些问题，包括从版本发展的过程中也有所进化，甚至做了不少自我否定。跟着spring屁股后面否定自己，甚至有口难言的，我想都不在少数！

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

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

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

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

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


从开始做java到现在，已经9年了。做的项目，有国家级的大项目，也有每日访问量500w的互联网项目，总结经验，ssh和项目质量，产品性能压根无关，也和项目维护更无关。倒是常见一些用ssh做互联网项目做的非常失败的，表现在开发速度慢，运行速度慢，系统运维难度大。

如果更公正的说，ssh可能适合一些小型的企业应用项目，除此，ssh和ssh倡导的一些理念丝毫排不上用场。

其实我也想了解下spring带来的真正的好处。
比如我IUserDAO dao=new UserDAO();
用spring 就是IUserDAO dao=beanFactory.getBean("userDAO");

假如以后我想把IUserDAO换成另外一种实现
IUserDAO dao=new UserDAO2();
对应spring: IUserDAO dao=beanFactory.getBean("userDAO2");

也许有人会说，我直接在spring的配置文件中将ID为userDAO的类的type改为UserDAO2就可以了，程序不用改动。但这又有什么太重大的优点呢？我用IDE的refactor一样可以马上将new UserDAO()换成new UserDAO2();

请问好处是什么？谁能告诉我？

一、企业应用软件市场本来仅仅是一个市场分类而已，仅此而已，这个市场本来在这里已经认定是java的市场了，还有什么意义？但是软件市场不仅仅是一个企业应用软件市场。

二、作为了一个古老的java程序员，我一直在不停的观察和研究最新的技术，不过这几年让我非常失望，java目前的发展方向绝对是一条歧路，违背了技术发展的规律。歧路的根本在于习惯了使用复杂和繁琐的办法去解决并不复杂的问题。

三、所谓的ioc,di已经成了spring的代名词，这个技术本身现在仍然有很大争议。di/ioc的价值和意义我认为还是不明确的，他缺乏一个有力需求的支撑，作为个人观点，我持有否定态度。但是这仍然是一种技术选择，优劣自然由市场来判断。

四、对于实现业务逻辑，单例和静态方法毫无区别，因为都意味着这是一个无状态的类。但是使用spring来达到这个目的，远远比直接使用语言特性来实现要愚蠢的多。使用某种技术仅仅是一种实现结果的过程而已，只要能更好更有效的实现，自然会选择更简便的办法。

五、至于资历，并无摆的意思，只是因为有些人看着眼扎的慌，呵呵。