这个类的实现看起来还是没什么问题，但是事实上是有问题的，我们可以写一个test指出问题在哪里。当我们没有对父类的所有细节加以注意时，问题就来了。
CompanyDetails c1 = new CompanyDetails("231412", "McDonalds Ltd", "McDonalds food factory", 120000.00);
CompanyDetails c2 = new CompanyDetails("231412", "McDonalds Ltd", "McDonalds restaurants", 60000.00);
Set<CompanyDetails> set1 = CompaniesFactory.createCompanies1();
set1.add(c1);
set1.add(c2);
Set<CompanyDetails> set2 = CompaniesFactory.createCompanies2();
set2.add(c1);
set2.add(c2);
Assert.assertEquals(set1.size(), set2.size());
我们构造了两个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接口的问题实际是由于不好的约定和对使用的接口需求的错误理解造成的。作为一个Java开发人员或架构师，你应该特别注意这样的事情，并遵守良好的编码习惯和做法。 越大的项目，这种问题就越显得重要。这里我总结了一个使用Comparable接口的最佳实践，可以避免这个错误。