尽量少用接口行不行

比较好奇你的头像是啥东西~！

又像膝盖，又像屁股。

http://www.google.com/imghp?hl=en&tab=wi
你懂的

http://mi9.com/wallpaper/stacy-wallpaper_13945/

我提点个人看法。
楼主首先要明白接口的作用，特别是为什么要用接口？使用接口带来的好处等。然后是接口和普通类的区别。

首先谈接口：
1、接口的使用，首先意味着你的类存在或者可能将来存在多态的情况；
2、接口的使用，另一个重要的目的在于隐藏实现类，也就是说，实现类将来可能随着业务的变化，需要被替换。打个比方，原来Connection是连接Oracle的，所以实现类里面用的是访问Oracle的代码，但是后来，需要使用SQLServer的数据库，实现类必须换成访问SQLServer，那么对于我们来说，自从重写实现类，然后替换原来的实现类即可；
3、接口的方法和参数是接口设计成功与否的关键，也是系统是否具备可维护性、可移植性的重要考量内容。

结合以上，建议楼主多看一下JDK的源码。

那么来说说普通类（非接口类）。
普通类就很简单了，比如相对通用，没有多态、后期需要被替换的可能性，那么就直接编写类，而不需要使用接口，典型的有util包下面的通用类等。


最后就是建议楼主多了解Spring框架，这样有助于楼主理解接口的意义和作用。

有些不需要AOP的类，没必要必要非要用接口吧。

接口的用处确实明显.比如DAO设计,service层调用接口然后对mysql的写一套实现,以后如果换Oracle了,就可以重新实现接口.

但是,事实上很多项目都是只用一个数据库的.而DAO类的方法经常要添加.结果每次改动都要copy一下函数声明...

你要不适用接口， 等到改动时你就会苦不堪言咯。

全是接口也未必是件好事，凡事都有度。

很多理论上的好处，比如数据库DAO接口，但很少看到有项目会换数据库，虽然使用接口，但是实际用处有待考证。

接口最大的用途莫过于抽象，但是个人感觉牵涉到具体业务逻辑的地方并没有那么容易抽象。

程序架构时你可以抽象提取，但是牵涉到具体业务逻辑的时候，还需要谨慎些，因为你不知道客户会提出怎样的需求，因为有时候连他们都不清楚自己需要什么。

当然，我说的是谨慎，没说不用，或者尽量少用，该用的时候还是要用。

说的有道理，但是如果是涉及到业务逻辑的代码，就不能简单的用JDK的设计思路去比较了吧。

想必您也做过类似订制的内部管理系统，客户的需求通常是含糊的，多变的，这时候他都无法确定自己需要什么样的结果，那程序员自然就很难抽象了。一个类两个类还好，但通常这种逻辑都是牵扯到非常多的类和方法的，可能非常难以抽象。