Jams Gosling(Java之父)说过，“想抛弃classes”当然，他的意思是，不是抛弃class本身，而是继承(extends 关系)。他想用接口(implements关系)来代替extends是更好的。我们应该尽可能的避免实现继承，原因如下：
1 失去灵活性，使用具体类会给底层的修改带来麻烦。
2 耦合问题，耦合是指两个实体相互依赖于对方的一个量度。程序员每天都在(有意识地或者无意识地)做出影响耦合的决定：类耦合、API耦合、应用程序耦合等等。在一个用extends的继承实现系统中，派生类是非常紧密的与基类耦合，而且这种紧密的连接可能是被不期望的。如B extends A ，当B不全用A中的所有methods时，这时候，B调用的方法可能会产生错误!
我们必须客观的评价耦合度，系统之间不可能总是松耦合的，那样肯定什么也做不了。而我们决定耦合的程度的依据何在呢？简单的说，就是根据需求的稳定性，来决定耦合的程度。对于稳定性高的需求，不容易发生变化的需求，我们完全可以把各类设计成紧耦合的(我们虽然讨论类之间的耦合度，但其实功能块、模块、包之间的耦合度也是一样的)，因为这样可以提高效率，而且我们还可以使用一些更好的技术来提高效率或简化代码，例如Java中的内部类技术。可是，如果需求极有可能变化，我们就需要充分的考虑类之间的耦合问题，我们可以想出各种各样的办法来降低耦合程度，但是归纳起来，不外乎增加抽象的层次来隔离不同的类，这个抽象层次可以是具体的类，也可以是接口，或是一组的类(例如Beans)。我们可以借用Java中的一句话来概括降低耦合度的思想："针对接口编程，而不是针对实现编程。
在我们进行编码的时候，都会留下我们的指纹，如public的多少，代码的格式等等。我们可以耦合度量评估重新构建代码的风险。因为重新构建实际上是维护编码的一种形式，维护中遇到的那些麻烦事在重新构建时同样会遇到。我们知道在重新构建之后，最常见的随机bug大部分都是不当耦合造成的 。
如果不稳定因素越大，它的耦合度也就越大。如果不稳定因素越大，它的耦合度也就越大。
某类的不稳定因素=依赖的类个数/被依赖的类个数
依赖的类个数＝ 在编译此类的时被编译的其它类的个数总和
怎样将大系统拆分成小系统，解决这个问题的一个思路是将许多类集合成一个更高层次的单位,形成一个高内聚、低耦合的类的集合，这是我们设计过程中应该着重考虑的问题！
耦合的目标是维护依赖的单向性，有时我们也会需要使用坏的耦合。在这种情况下，应当小心记录下原因，以帮助日后该代码的用户了解使用耦合真正的原因。