请教：关于接口的设计

99%的继承都是在误用，Interface和aggregation 能够承担大部分的继承工作。


接口是否定义清晰，来自于两个方面:第一个是行业经验，第二个是延迟定义。
对于具有行业经验的人来说，如何定义接口的原则是惯用法。
延迟定义，是说在你没有任何确凿的证据的情况下不要随便定义接口，
直接用aggregation 就可以。

Agreeation是什么？一种模式嘛？
sorry，我没有听说这种。在google上也搜不到。
能说说嘛？

aggregation  就是聚合的意思。
一个抽象类总能分解成一个类和若干接口的聚合，接口之间聚合的重要性在于他们之间是正交的。如果一个抽象类能够进行分解，那么就说明这个抽象类不是正交的。

接口的作用在于对可变性进行了封装,从而在具体实现发生改变时不用修改代码就能实现程序功能的改变,简单的说就是实现了可插入性.java的接口的缺点在于接口的更改必然导致所有实现此接口的类的更改,所以接口+抽象类成为最好的解决办法.
个人以为:一般的业务系统的开发,在框架已经打好的情况下,如果你认为系统中的可变因素不大,就完全没有必要使用接口,抽象类.而框架类,通用类的设计,接口的作用就显现出来了.

我也认为对一些不多变的通用操作在抽象类里实现，特别是些操作要被很多子类使用时

pufan 写道
    楼上啊，那就真是错了啊，越是业务逻辑系统中就越要用接口，进行隔层了，简单地讲，当你开发一个系统，你本来是用JDBC实现数据库访问，可是后来要用hibernate，如果你不用DAO模式（其实就是工厂模式，也就是访问接口），那么你怎么解决。你不要告诉我你永远都不会改，那么你的程序就没有任何一丝的维护性和移植性可言。[/list]

--------------------------------------------------------------------------------
跨层的访问当然要实现接口了.但在一层中那,你不要告诉我为每个类都写接口,然后继承此接口的抽象类并实现工厂方法,你累不累.凡事无绝对,只要你认为你的类是相对稳定的,不会发生变化的,消费这个具体类实例的客户端完全可以依赖这个类,就没有必要实现接口抽象类,毕竟开发效率速度也是相当重要的.

to 凤舞凰扬：
我觉得 pufan 和你说的并不矛盾啊，呵呵。我是赞同接口应该尽早地定下来的，当然这对设计人员提出了更高的要求。他必须真正理解了业务，并且尽可能地预测到系统哪些地方有可能发生变化，通过适当分层（例如增加一个 DAO 层）的方法封装这些变化。
接口分成两类，大的接口和小的接口。大的接口代表了系统的体系结构，就是各子系统或各层之间的边界，早定下来开发人员就可以彼此并行工作，这对于提高开发效率是非常重要的。至于一些小的接口可以在开发过程中逐渐加进来，采用自底向上的方式产生也是可以的。

另外可移植性和灵活性也是一把双刃剑，衡量的标准就是所要解决的业务问题是否真的需要。例如我做一个短期的项目，客户指定必须使用 Oracle，我也没有把这个项目产品化的打算，这个时候开发效率就成为了压倒一切的重要因素，就没有必要考虑太多如何移植到 SQL Server 上的问题。因为客户从来也没有考虑过 SQL Server。10 多年前 Linus 和坦尼鲍姆论战的时候说“可移植性是写不出代码的人的借口”，我一直觉得这句话很有道理。后来事实也证明 Linux 是完全可以移植的。每个阶段有每个阶段的主要问题，不能笼统地认为任何时候可移植性都是最重要的问题。还有如果灵活性并不是业务问题所需要的，那么就没有必要叠床架屋式地添加过多的层次。在这方面我非常赞同 XP 中力求简单、“不为明天而设计”的观点。

哈哈，楼上误解我的意思了，我什么时候说过每个类都要写接口呀？？那抽象类、实体类、静态工具类做什么用呢？
   要做好一个系统，那么，我就要知道什么时候用接口、什么时候用抽象类、什么时候用静态方法，如此而已。
   我从来没有要求你去把现在的系统全部改成接口设计，呵呵，但是你没有发觉你对于接口的使用有一种排斥感么？越有许多人像你推荐，那么你越反感，呵呵，排斥心理很重，对于自身的提高是不好的。
    我们知道一个好的设计不是一天就成的，也不是把理论一说就成的，更重要的是实践，如果你不尝试把现有系统进行重构，包括设计的重构，也包括代码实现的重构，那么你永远都只能是优秀设计的门外汉。
    没有一个人可以在系统正式编码完成前就能把所有的接口设计好，那是不现实的，更是不客观的，世界上没有几个人可以做到。为什么XP提倡重构，它的目的很简单，就是让你的设计在每一次重构中完善，让你自己在每一次重构中获得设计的提高。
    另外，评价一个软件，一个系统，是否优秀，最集中体现在三个方面：健壮性、维护性、移植性。好的设计可以给你带来后面两种的实质性的提高。

     我从来没有软件系统盲目去追求什么移植性，比如说，如果我们太多考虑数据库的移植，那么每个数据库的特性都会用不到，每个数据库的优秀功能我们都用不到，用的只是TSQL92的简单命令罢了。我从来都是反对这样的，这也是可移植性放在第三位的原因。
    需求决定软件，如果客户只是一个很小的需求，比如只要求mysql数据库的基本使用，这个时候去考虑oracle的移植，那是这个系统的系统分析员有毛病。
    但是，另外又说，如果做软件，在思想上老是只考虑特殊性这点，对于好的设计又不是很懂，这个时候谈做软件只做需要的，而丝毫不让自己从思想到实际上进步与武装，那么你永远都会比别人差。
    不要埋怨别人做的系统总那么大，总要考虑那么复杂的架构，而自己做的永远都只是小的，都只是简单的。人都是从小做到大，要在小的系统中领悟出大的道理，在时间、能力许可的情况下，把自己小的系统做得与大系统一样有好的架构有好的设计，逐步提高了，那么不久你就可以接做大系统了。
    永远记住，我们不是大师，我们没有资格去谈什么系统适用就好。我们要成长，我们要提高，我们需要各种各样的机会，看好每一个小处，认真对待它，目光长远些，这样才能成长。