Java API设计指南4

　　我个人不认为让大部分方法都成为final是一个好的设计方案。根据我个人的经验，这种处理方式将会严重的降低代码的复用度。

　　如果更极端的说一下：也许不应该有private方法，所以的方法都应该是protected甚至是public，这样可以有益于复用度。当然这样处理带来的一个明显缺点就是没有人知道哪个方法可以被安全的复写(overrid)。

　　(译注：这也太极端了，如果这样，一个API的规模恐怕会是原来的10倍以上，不要说复用，恐怕怎么用我都不知道了，想想一下一个1000个类，10000个public方法的API包吧)。

　　Gregor Zeitlinger写道：

　　在什么情况下我们要同时提供接口和抽象类呢。举个例子，Java的集合框架中提供了List这个接口和AbstractList这个抽象类。

　　接口的好处在于

• 　　多继承
• 　　其实现子类可以有最大的灵活性
• 　　能够将API的描述信息与其实现彻底分离

　　类的好处在于：

• 　　提供通用的方法，避免重复代码
• 　　能够支持接口的演化

　　Eamonn McManus 写道：

　　Bloch在《Effective Java》中强烈建议在提供一个接口的同时，尽量提供一个实现了该接口的抽象基类。这话在Java集合框架的设计体现的淋漓尽至，他老兄就是Collection框架的主设计师。这个设计的模式在许多场景中都是非常有用的，不过也不要把它当作金科玉律，一言而敝之：不要为模式而模式。

　　即使你使用了接口+基类的方式，也不能保证你API的演化，除非你只在基类中添加方法，而不在接口中添加方法，这种情况带来的坏处就是混乱，如果一个类想调用这个新添加的方法，因为接口中没有添加这个方法，所以通过接口是无法调用的，那么只能将它强行转型，然后再调用，但有时候又很难确认你的强行转型是正确，糟糕的ClassCastException又出现了。除非你能保证所有的子类都继承这个基类，不过这种情况和中彩票的机会相差不多吧。

　　现在来谈一下unchecked exceptions和C#的问题，许多人都觉得在Java中Checked exceptions并不是一个缺陷，或者说它不是一个严重的问题。但我不这样认为：象IOException这种异常，应该是Checked Exception，以便由编译器来提醒程序员时要正确处理资源问题，这是一件好事，但是在Java中，有大量不必要的异常成为Checked Exception，这些Checked Exception却给程序员带来了许多麻烦。

Robert Cooper 写道：

　　即使你使用了接口+基类的方式，也不能保证你API的演化。

　　我认为，如果可能的话，在为基类添加新方法的同时，也应该在接口中添加新的方法。我向来如此，也没有出现过什么问题。

　　很清楚的一点就是，如果这样做了，接口的定义改了，如果一个类是直接实现这个接口，就需要实现所有的方法。

　　Michael Feathers 写道：

　　在什么环境下我们要同时提供接口和抽象类呢。

　　接口+基类并不是可以用于所有的场景!

　　大部分情况下，我都会使用接口+基类这种方式，不过这种方式也会带有几个缺点。

　　如果你的API比较复杂，很难找到一个准确的入口点来使用你的API。比如说我需要一个IX，但是我要一步步的向下查找AbstractX，以及相关的实现，这种接口+基类的方式加深了继承的层次，增加了API的复杂度。