继承和接口

这有点是这个问题的后续问题.

假设我有一个继承树,如下所示:

Car -> Ford -> Mustang -> MustangGT

为每个类定义接口有什么好处？例:

ICar -> IFord -> IMustang -> IMustangGT

我可以看到,也许其他类(如Chevy)将要实施Icar或IFord,甚至IMustang,但可能不是IMustangGT因为它是如此具体.在这种情况下接口是多余的吗？

另外,我认为任何想要实现的类IFord肯定都希望通过继承来使用它的一个继承,Ford以免重复代码.如果这是给定的,那么实施的好处是IFord什么？

根据我的经验,当你有几个类需要响应相同的方法或方法时,最好使用接口,以便它们可以被其他代码交替使用,这些代码将针对这些类的通用接口编写.接口的最佳用途是协议很重要,但每个类的底层逻辑可能不同.如果您将复制逻辑,请考虑抽象类或标准类继承.

在回答问题的第一部分时,我建议不要为每个类创建一个界面.这会不必要地混乱你的类结构.如果您发现需要界面,可以随时添加.希望这可以帮助!

亚当

我也同意adamalex的回应,即接口应该由应该响应某些方法的类共享.

如果类具有相似的功能,但在祖先关系中没有直接相关,则接口将是将该函数添加到类而不在两者之间复制功能的好方法.(或者有多个实现只有细微差别.)

虽然我们使用汽车类比,一个具体的例子.假设我们有以下类:

Car -> Ford   -> Escape  -> EscapeHybrid
Car -> Toyota -> Corolla -> CorollaHybrid

汽车有wheels,可以Drive()和Steer().所以这些方法应该存在于Car类中.(Car该类可能是一个抽象类.)

顺便说一句,我们得到了Ford和之间的区别Toyota(可能是作为汽车标志类型的差异,也可能是一个抽象类.)

然后,最后我们有一个Escape和Corolla类,它们是完全实现为汽车的类.

现在,我们怎么能制造混合动力汽车？

我们可以有一个子类的Escape是EscapeHybrid增加了一个FordsHybridDrive()方法,和子类Corolla是CorollaHybrid与ToyotasHybridDrive()方法.这些方法基本上都是做同样的事情,但我们有不同的方法.呸.似乎我们可以做得更好.

让我们说混合动力车有一种HybridDrive()方法.由于我们不想最终拥有两种不同类型的混合(在一个完美的世界中),因此我们可以创建一个IHybrid具有HybridDrive()方法的接口.

因此,如果我们想创建一个EscapeHybrid或CorollaHybrid类,我们所要做的就是实现IHybrid接口.

对于一个真实世界的例子,我们来看看Java.可以将对象与另一个对象进行比较的类实现该Comparable接口.顾名思义,接口应该是一个可比较的类,因此名称为"Comparable".

同样值得关注的是,Java教程的Interfaces课程中使用了一个汽车示例.

您根本不应该实现任何这些接口.

类继承描述对象是什么(例如:它的身份).这是好的,但是大多数的对象什么时候是,远比什么对象不那么重要呢.这是接口的用武之地.

接口应该描述的对象是什么呢),或它就像什么.通过这个我的意思是它的行为,以及在给定行为的情况下有意义的操作集.

因此,良好的接口名称通常应该是形式IDriveable,IHasWheels等等.有时,描述此行为的最佳方式是引用一个众所周知的其他对象,因此您可以说"行为就像其中之一"(例如IList:),但恕我直言,这种形式的命名是少数.

鉴于这种逻辑,接口继承有意义的场景与对象继承有意义的场景完全不同- 通常这些场景根本不相关.

希望能帮助您思考实际需要的接口:-)