Java的Comparable接口提供一个对实现了这个接口的对象列表进行排序的办法。原始的排序对于简单的对象来说具有意义，但是当我们面对复杂的面向对象的业务逻辑对象时，事情变得复杂的多。从业务经理的角度来看，一些交易对象的自然顺序可能是按照交易的价值来排序的，但是从系统管理员的角度来看，这个排序的规则可能是交易的速度。所以在大多数情况下，并没有明确的业务领域对象的自然排序规则。

    假设我们找到了一个需要排序的类，比如说Campany。我们把公司的offical name作为主关键字，把id作为次要关键字。这个类的实现如下：

这个实现看起来没问题，假设现在这个类提供的信息不够使用，我们又创建了这个类的一个子类CompanyDetail类用以扩展他。例如我们想以一个表的形式显示公司的信息，我们就可以用这个类。

这个类的实现看起来还是没什么问题，但是事实上是有问题的，我们可以写一个test指出问题在哪里。当我们没有对父类的所有细节加以注意时，问题就来了。

    我们构造了两个set，但是结果是assert的结果是不相等。这是为什么？其中一个set是一个HashSet，他依赖对象的hashCode()和equals()方法，但是另一个是TreeSet，他只是依赖Comparable接口，而这个接口在子类中我们并没有实现。在领域对象被扩展的时候这是很常见的一个错误，但是更重要的是这是不好的编码约定造成的。我们使用Apache
Commons包中的builder来实现hashCode(),equals().和compareTo()方法。这些builder提供了appendSuper()方法，此方法指示了如何调用这些方法在父类中的实现。如果你看过Joshua Bloch 的Effective Java，你会发现这是错误的。如果我们在子类中添加成员变量，在不违反对称规则的情况下，我们就不能正确的实现equals()方法和compareTo()方法。我们应该使用组合的方式而不是继承。如果我们使用组合的方式构造CompanyDetails，对于Comparable接口来说没有任何问题，因为我们没有自动的实现，而且在默认的情况允许不同的行为。而且我们也能满足正确的equals()和hashCode()的需求。

·了解你需要创建的领域对象，如果对象没有明确的排序规则，请不要实现Comparable接口。

·更多的使用Comparator而不是Comparable，Comparator在更多的业务使用方式时要显得更为实用。

·如果你需要创建依赖Comparable接口的接口或者库，如果可能的话你提供自己的Comparator实现，否则就写一个良好的文档指明在你的接口实现类中如何实现。

·遵守良好的编码习惯和做法。Effective Java是很好的推荐。