从基类继承的接口是否应该在子类中显式实现？

发布于 2024-07-10 09:12:41 字数 472 浏览 9 评论 0原文

我的问题是，如果通过扩展已经实现它的类来隐式实现的接口，如果该类想要宣传它履行该接口的契约的事实，则应该由该类显式实现。

例如，如果您想编写一个类，它满足接口java.util.List 的约定。您可以通过扩展已实现接口 List 的类 java.util.AbstractList 来实现此功能。您是否明确声明您实现了 List？

public class MyList extends AbstractList implements List

还是使用隐式方式来节省打字？

public class MyList extends AbstractList

哪种方式被认为是更好的风格？您有什么理由选择这种或另一种方式？在什么情况下您更喜欢方式 1 或方式 2？

原文

My question is, if an interface that is implemented implicitly by extending a class that already implements it, should be explicitly implemented by the class, if the class wants to advertise the fact, that it fulfills the contract of that interface.

For instance, if you want to write a class, that fulfills the contract of the interface java.util.List. You implement this, extending the class java.util.AbstractList, that already implements the interface List. Do you explicitly declare, that you implement List?

public class MyList extends AbstractList implements List

Or do you save typing by using the implicit way?

public class MyList extends AbstractList

Which way is considered better style? What reasons do you have to prefer one way or another? In which situations you would prefer way 1 or way 2?

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

蓝眼泪 2024-07-17 09:12:41

避免冗余。使用方法2。

使用@Override进行覆盖。

回复收藏 0 原文

泅人 2024-07-17 09:12:41

这不是一个“风格”问题。如果您要扩展已实现 List 的 AbstractList，则无需显式实现 List。

这不仅仅是节省打字的问题。由于附加的“工具列表”是多余的，有人可能会花一些时间试图找出它的存在原因。你本质上是在写一个已经成为语言一部分的保证。

回复收藏 0 原文

叫嚣ゝ 2024-07-17 09:12:41

我很久以前在我的博客上问过同样的问题。如果您有兴趣了解其他人的想法，那里也有一个很长的讨论。有趣的是，这两种策略都是在 JDK 中采用的。

我最终认为对此制定硬性规定是没有意义的 - 最好对我想要传达的内容使用最佳判断。

回复收藏 0 原文

聚集的泪 2024-07-17 09:12:41

如果您关心类的用户能够通过 Class.getInterfaces() 获取已实现接口的列表，那么您的类应该提及其“实现”列表中的所有接口。 Class.getInterfaces() 不会返回超类实现的接口。以下程序将打印 1，然后打印 0。

import java.io.Serializable;

class Test implements Serializable {
    class Inner extends Test {
    }

    public static void main(String[] argv) throws Exception {
        System.out.println(Test.class.getInterfaces().length);
        System.out.println(Inner.class.getInterfaces().length);
    }
}

If you care about a user of your class being able get a list of implemented interfaces via Class.getInterfaces() then your class should mention all the interfaces in its' implements list. Class.getInterfaces() will not return the interfaces implemented by super classes. The following program will print 1 and then 0.

import java.io.Serializable;

class Test implements Serializable {
    class Inner extends Test {
    }

    public static void main(String[] argv) throws Exception {
        System.out.println(Test.class.getInterfaces().length);
        System.out.println(Inner.class.getInterfaces().length);
    }
}

回复收藏 0 原文

油焖大侠 2024-07-17 09:12:41

我会更逐字地说。为什么要让其他人阅读你的代码必须查找类实现了什么？它清楚地表明了类的继承功能。但我会尽力保持项目中所有代码的一致性。如果你只在一个地方这样做，那会很混乱，但如果你始终如一地这样做，他们就会意识到冗余。

旁注：Java 中有如此多的类，谁知道它们呢？更重要的是，谁知道每个类是从哪些类实现的？您多输入几秒钟可以为其他开发人员节省一两分钟的时间来查看课程。

回复收藏 0 原文

尐偏执 2024-07-17 09:12:41

其他评论者说你应该避免冗余，我同意他们的观点。

为了回答一般问题，我能想到的说明两者的唯一情况是，如果您扩展（比方说）AbstractFrotzer 并实现了 Frobner，AbstractFrotzer 实现了 Frobner，但您有理由相信将来可能不会。如果 AbstractFrotzer 确实是抽象的，那么它甚至可能无法实现 Frobner 本身的所有方法。这意味着有人可以更改 AbstractFrotzer 的契约，而无需更改您的类或依赖于您的类成为 Frobner 的任何其他代码。然而，我认为这是一种非常罕见的情况，即使发生这种情况并且您的类仅扩展了 AbstractFrotzer，也可以很容易地对其进行快速语义检查，并在必要时向其添加 Implements 子句：那一点。

回复收藏 0 原文

木緿 2024-07-17 09:12:41

虽然我通常坚持选择 2，但我会冒险认为，选择 1 在适用时实际上在更多情况下是合适的。

代码的可用性和可理解性很重要。我们必须问自己的问题是，使用或看到对该类的引用的开发人员是否会直观地理解该类实现了该接口（因此本质上是一个子类型）。

在典型情况下，在编写良好的类中，类的名称应该明显表明它实现了接口。添加接口只是一种冗余。

但是，如果类名没有明确说明它实现的接口，并且尽管有味道，但事情就是这样，并且这个名称将被卡住，那么添加实现来显式指示接口是有意义的。这也很好，以防将来有人更改层次结构，这在像这样不直观的继承中是可能的。

回复收藏 0 原文

一萌ing 2024-07-17 09:12:41

虽然在子类中实现接口是多余的，但实现它是一个很好的实践。因为有人可能会从超类中删除已实现的接口。

回复收藏 0 原文

神经暖 2024-07-17 09:12:41

无需明确执行此操作，如上面的答案所述。

但有时，你神秘地不得不。我有一些包含用于 JIRA 插件开发的类的库，并且 class:

public abstract class Condition extends AbstractWebCondition

实现失败，直到我在类声明中明确添加“implements com.atlassian.plugin.web.Condition”（尽管如此， AbstractWebCondition 确实实现了它）。幸运的是找到了解决方案在这里。

我不知道这种行为的起源，但我们就在这里。从 JIRA 7.0.0 更新到 JIRA 7.13.18 时观察到了这一情况。

No need to do it explicitely, as stated in answers above.

But sometimes, you mysteriously have to. I have some library with classes for JIRA plugins developing, and class:

public abstract class Condition extends AbstractWebCondition

implementations failed until I've added " implements com.atlassian.plugin.web.Condition" in class declaration explicitely (though, AbstractWebCondition do implements it). Solution was fortunately found here.

I don't know origins of such behaviour, but here we are. It was observed while updating from JIRA 7.0.0 to JIRA 7.13.18.

回复收藏 0 原文