问题描述
我继承了一些遗留Java（1.4）代码，这个设计决定定期出现。我无法理解是否有任何目的或理由。
I inherited some legacy Java (1.4) code and this design decision appears regularly. I can't understand if there's any purpose or reason to it.
public interface SoapFacade extends iConfigurable{ }
public class SoapFacadeBase implements SoapFacade{
...
}
public class SoapFacadeImpl extends SoapFacadeBase implements SoapFacade{
...
}
据我了解接口（我的实验已经加强），没有任何目的同时拥有父母和子实现相同的接口。在这种情况下， SoapFacade 中的所有内容都在 SoapFacadeBase 中实现，但 iConfigurable中的方法在 SoapFacadeImpl 中实现。但是，这并不需要 SoapFacadeImpl 实现 SoapFacade 。
As I understand interfaces (and my experimentation has reinforced), there is no purpose to having both the parent and the child implement the same interface. In this scenario, everything from SoapFacade is implemented in SoapFacadeBase, but the method in iConfigurable is implemented in SoapFacadeImpl. However, that doesn't create a need to have SoapFacadeImpl implement SoapFacade.
是否有一些我不了解的接口会给这种模式一些目的或好处？除了缺乏清晰度之外，还有潜在的成本会导致重构吗？或者它是否应该为了清晰/简单而重构？
Is there something I don't know about interfaces that would give this pattern some purpose or benefit? Are there underlying costs beyond lack of clarity that should drive refactoring it? Or should it simply be refactored for clarity/simplicity?
推荐答案
没有。从技术上讲，这是完全多余的。
No. Technically, it is completely redundant.
它 然而记录了你想要的事实 SoapFacadeImpl 是一个 SoapFacade 并确保你得到编译错误，如果你（或其他人）决定删除实现SoapFacade 。
It does however document the fact that you intend SoapFacadeImpl to be a SoapFacade and it ensures that you get a compile error, if you (or someone else) decides to remove implements SoapFacade from the base class.
您可以在标准Java Collections API中的任何位置看到此模式。 ArrayList 实现 List ，即使它的基类（ AbstractList ）已经，确实如此。同样适用于 HashSet / AbstractSet 和 Set 界面。
You see this pattern everywhere in the standard Java Collections API. ArrayList implements List even though its base class (AbstractList) already, does. Same holds for HashSet / AbstractSet and the Set interface.
这篇关于为什么父类和子类都实现相同的接口？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！