blocks|key|1021872|text|"I“前缀并不是真正的Java方式。这是更多的C#。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1021873|对于Java，我通常使用以下约定：|1021874|接口：生成器|unordered-list-item|offset|length|style|BOLD|1021875|抽象类：+AbstractBuilder|1021876|混凝土类：+BuilderImpl，DefaultBuilder，MyBuilder等|1021877|我认为这与Java标准(分别为Map、AbstractMap、HashMap+)相当一致。|1021878|至于用抽象类替换接口，则需要重构。我认为最好为所有方法返回、数据成员类型、局部变量类型和参数使用接口。抽象类是(或应该是)实现细节。|1021879|回到Map示例，这意味着一切都是Map。您可以创建自己的Map子类。JDK为您提供了一个帮助类，它执行大多数样板。如果您根据抽象类声明了成员，您将被迫使用它，这不是最好的结果。|1021880|entityMap^0|0|0|0|3|0|0|4|0|0|5|0|0|0|0^^$0|@$1|2|3|4|5|6|7|W|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|X|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|Y|8|@$G|Z|H|10|I|J]]|9|@]|A|$]]|$1|K|3|L|5|F|7|11|8|@$G|12|H|13|I|J]]|9|@]|A|$]]|$1|M|3|N|5|F|7|14|8|@$G|15|H|16|I|J]]|9|@]|A|$]]|$1|O|3|P|5|6|7|17|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|18|8|@]|9|@]|A|$]]|$1|S|3|T|5|6|7|19|8|@]|9|@]|A|$]]|$1|U|3|-4|5|6|7|1A|8|@]|9|@]|A|$]]]|V|$]]

An "I" prefix isn't really the Java way. That's more C#.

For Java, I generally use this convention:

<ul>
<li>Interface: Builder</li>
<li>Abstract Class: AbstractBuilder</li>
<li>Concrete Class: BuilderImpl, DefaultBuilder, MyBuilder, etc</li>
</ul>

I think that agrees fairly well with Java standards (Map, AbstractMap, HashMap respectively).

As for replacing interfaces with abstract classes, that requires a refactor. I think it's a better idea to use interfaces for all method returns, data member types, local variable types and parameters. Abstract classes are (or should be) an implementation detail.

Going back to the Map example, that means everything is a Map. You can create your own Map subclass. The JDK provides you a helper class that does most of the boilerplate. If you declared members in terms of the abstract class, you'd be forced to use it and that isn't the best outcome.

blocks|key|1021913|text|不，您不能轻松地做到这一点，因为您可能也是从另一个类继承，而且Java不允许从类中进行多次继承。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1021914|最好有一个标准的命名结构。在Java中，我不确定您是否需要使用I前缀；我认为它是able后缀。不管是哪种方式，都要采用一种，并使之保持一致。|offset|length|style|CODE|1021915|-编辑|1021916|对于抽象类，我的首选是Base后缀，但每个后缀都是自己的:)|1021917|entityMap^0|0|V|1|14|4|0|0|B|4|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@$D|P|E|Q|F|G]|$D|R|E|S|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|T|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|U|8|@$D|V|E|W|F|G]]|9|@]|A|$]]|$1|L|3|-4|5|6|7|X|8|@]|9|@]|A|$]]]|M|$]]

No, you can't do that easily because you may be also inheriting from another class, and Java doesn't allow multiple inheritance from classes.

It is better to have a standard naming structure. In Java, I'm not sure you need to adopt the <code>I</code> prefix; I think it is the <code>able</code> suffix. Either way, adopt one, and make it consistent.

-- Edit

With abstract classes, my preference is for a <code>Base</code> suffix, but to each his own :)

blocks|key|982820|text|抽象类与特定事物上的接口有很大不同。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|982821|给定的类可以实现任意数量的接口，但只能扩展一个抽象类。|982822|因此，应该以非常不同的方式对待它们，而不是在命名方面。为接口选择一个简短的描述性名称--您将再次看到它。例如，List是一个接口，但ArrayList是类。|982823|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

An abstract class is very different from an interface on one particular thing.

A given class can implement any number of interfaces, but only extend one abstract class.

Hence, they should be treated very differently, but not in naming terms. Choose a short, descriptive name for the interfaces - you will see it a LOT again. For instance List is an interface, but ArrayList is the class.

blocks|key|982855|text|我和我的同事们正在使用Java的漏洞日|type|unstyled|depth|inlineStyleRanges|entityRanges|data|982856|接口:+IDialog|unordered-list-item|982857|摘要:+AbstractDialog|982858|班级:+DefaultDialog，WarningDialog|982859|抽象类实现了大多数常用的接口方法或最常用的util方法。|982860|您不必从抽象类中扩展。如果实现的方法对要生成的类有用，则应扩展抽象类。|982861|否则，您应该实现接口并再次实现这些方法。|982862|您只从一个类扩展，所以如果您只能使用50%25的方法，那么从抽象类扩展时就没有意义。|982863|entityMap^0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|T|8|@]|9|@]|A|$]]|$1|E|3|F|5|D|7|U|8|@]|9|@]|A|$]]|$1|G|3|H|5|D|7|V|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|W|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|X|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|Y|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|Z|8|@]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|10|8|@]|9|@]|A|$]]]|R|$]]

I am working with Java the hole day and my colleagues and i are using

<ul>
<li>Interface : IDialog</li>
<li>Abstract: AbstractDialog </li>
<li>Class: DefaultDialog, WarningDialog</li>
</ul>

Abstract classes implements most common interface methods or most used util methods.

You do not have to extend from the Abstract class. You should extend from the Abstract class, if the implemented methods are usefull for the class you want to generated.

Otherwise you should implement the interface and implement the methods again.

You extend from 1 class only, so it makes no sence when you extend from the Abstract class if you only can use 50% of the methods.

blocks|key|2508665|text|Java中的接口以“able”结尾。代表:克隆，系列化。因此，如果可能的话，您可以选择一个以“able”结尾的名称。实现接口的抽象类应该以名称“抽象”开头。例如:+abstractLinkedList。具体的类不受任何这样的命名约定的约束，除非它们应该有意义，并以大写字母开头。我建议您选择以“able”结尾的接口名称，或者可以前缀i(最后，不建议使用java，而是使用MS语言(如c#)中的默认命名约定)来区分接口与类实现。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2508666|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Interfaces in Java end in 'able'. For Ex: Cloneable,Serialisable. So if possible you can choose a name that ends with 'able'. An abstract class which implements an interface should start with name 'abstract'. for ex: abstractLinkedList. The concrete class are not subjected to any such naming convention other than that they should make sense and start with a capital letter. I would suggest you to choose interface name that ends with 'able' or you can prefix I (last resort, not recommended for java but the default naming convention in MS languages like c#) to differeniate your interface from class implementation

blocks|key|2508688|text|@+janetSmith，您可以坚持使用cletus答案来使用Car作为接口名，使用CarImpl作为实现car接口的类。唯一的问题是，粗略地看一下“Car”并不表示它是一个接口还是一个类，除非我们也看到了CarImpl。如果需要，可以使用“i”作为接口名称的前缀。这是微不足道的违规行为。Java实践表明。您可以签出这里接口名称，当实现它的类显示behaviour.For+Ex时，它应该以moveable结尾:如果car的子类提供了诸如move、park等行为，则可以具有可移动、可解析的接口名称。这适用于没有后缀“able”的动词的接口名称。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|2508689|-编辑:我的意见支持ICar。|2508690|entityMap|0|LINK|mutability|MUTABLE|url|http://www.javapractices.com/topic/TopicAction.do?Id=58^0|4F|2|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@$A|O|B|P|1|Q]]|C|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@]|C|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|C|$]]]|G|$H|$5|I|J|K|C|$L|M]]]]

@ janetSmith,
well you can stick to cletus answer to use Car as interface name and CarImpl as the class that implements car interface. The only problem is a cursory look at 'Car' doesnt indicate whether it is an interface or a class unless one also looks at CarImpl. If you want, you can stick to prefixing interface names with 'I'. Its a trivial violation. Java practices suggests that. you can check it out <a href="http://www.javapractices.com/topic/TopicAction.do?Id=58" rel="nofollow noreferrer">here</a> 
Interface names should end with able when the class that implements it exhibits that behaviour.For Ex: if a sub class of car provided behaviour like move, park,etc. you can have interface names like moveable, parkable. this applies for interface names that are verbs without the suffix 'able'.

--EDIT : My opinion go for ICar.

Is that important to differentiate between Abstract class and interface class?

Abstract class is merely an interface class, with some concrete methods.

If the abstract class shares the same prefix "I" with Interface class, we can easily upgrade our interface class to abstract class, by introducing new logic etc.

UPDATE

The reason why I am asking this is, interface impose some limitation when the project grows.
For instance,

If one interface has been "implemented" by thousand classes, and at some point we need to introduce a few new methods in the base class, we will have to fix all the sub classes.

Abstract class provides flexibility in terms of functional expansion, as it can provide default implementation without affecting sub classes.

That's why I got the idea of using interface and abstract class interchangebly.

<pre><code>ICar car = new Merz(); // ICar can be interface or abstract class
</code></pre>

However, when i think about it again, we still have to change all the sub classes, due to the fact that the class declaration forces us to use "extends" or "implements" at the very beginning.

So I think there is no option for doing polymorphism on abstract/interface class.

Should we need to differentiate between Interface class and abstract class, in terms of naming convention?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

区分抽象类和接口类是否重要？抽象类只是一个接口类，有一些具体的方法。如果抽象类与Interface类具有相同的前缀"I“，则可以通过引入新的逻辑等方法，轻松地将接口类升级为抽象类。更新我问这个问题的原因是，当项目增长时，界面会施加一些限制。例如,如果一个接口已经被上千个类“实现”了，并且在某个时候我们需要在基类中引入一...

问在命名约定方面，我们是否需要区分接口类和抽象类？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在命名约定方面，我们是否需要区分接口类和抽象类？EN