我最近不得不将一个简单的类分为两个版本,一个是旧版客户端版本的Legacy版本,另一个是迁移到单独界面的较新版本。
由于存在许多常见代码,我将其拆分为具有2个具体类的抽象类。结构如下:
interface ParentInt {
// Common methods
}
interface ChildIntA extends ParentInt {
// Legacy methods
}
interface ChildIntB extends ParentInt {
// New model methods
}
abstract class AbstParentClass implements ParentInt {
// ...
}
class LegacyConcreteClass extends AbstParentClass implements ChildIntA {
// ...
}
class NewConcreteClass extends AbstParentClass implements ChildIntB {
// ...
}
我想知道的是,我是否会遇到任何陷阱,因为AbstParentClass实现了ParentInt,这两个具体的类也实现了这个接口的子类?这种情况可能有更好的模式吗?
无论AbstParentClass是否具有此implements指令,我的代码目前都可以正常工作。实际上,因为两个具体类在不同的线程中分别实例化,所以AbstParentClass实际上从未在其他地方直接引用。
在我的情况下,接口是API的一部分,因此不能从我的POV中更改。
答案 0 :(得分:2)
没有技术问题。在您的应用程序中它是否有意义是一个单独的问题,但我们还不足以回答这个问题。
可能存在或可能不存在问题的另一个问题是新接口专门与传统接口绑定。如果传统界面消失了,你需要解除两者的关系,或者保持原状。
通过让新类实现两个接口来保持它们分离可能更容易。扩展抽象基类是否有意义变得有点模糊。
答案 1 :(得分:1)
这种方法没有问题。我理解你对明显的“多重继承”的关注,但Java处理接口的方式确保了这种事情从来都不是问题。具有相同签名的接口方法是“融合的”,只允许或需要一种实现方法,无论继承了多少相同的接口方法。