Suppose I have an abstract class named Task.
Is there a standard or convention that would suggest I should name it AbstractTask instead?
-
Naming conventions listed here: oracle.com/technetwork/java/codeconventions-135099.html suggest no, though this link: stackoverflow.com/questions/1006332/… says you could and it wouldn't be a terrible thing if you did.– FrustratedWithFormsDesignerJun 13, 2012 at 18:35
-
In C# the standard convention is to Suffix with '*Base'.– DenOct 3, 2014 at 10:06
Add a comment
|
13 Answers
According to Bloch's Effective Java (Item 18) the Abstract prefix is a convention used in a special case.
You can combine the virtues of interfaces and abstract classes by providing an abstract skeletal implementation class to go with each nontrivial interface that you export. ... By convention, skeletal implementations are called AbstractInterface, where Interface is the name of the interface they implement.
But Bloch also points out that the name SkeletalInterface would have made sense, but concludes that
the Abstract convention is now firmly established.
As other answers have pointed out, in general there is no reason to apply this naming convention to all abstract classes.
There is no convention. It's all about what will help you, as the developer, code faster and better, and help others understand your code.
Ask the people who will be seeing and maintaining the code. What would they rather see? What will make it easier on them? Then name it based on what they'd like.
On another note, Code Conventions for the Java Programming Language: 9. Naming Conventions suggests no requirement:
Class names should be nouns, in mixed case with the first letter of each internal word capitalized. Try to keep your class names simple and descriptive. Use whole words-avoid acronyms and abbreviations (unless the abbreviation is much more widely used than the long form, such as URL or HTML).
No. Intellisense will trivially tell me if it is abstract, so you're just violating DRY here.
-
26-1 Adding
abstractto a class name doesn't violate DRY, and not everybody uses intellisence. For example, what do you do if you are reading the code on a web page, or if it is part of a patch you are looking at in a plain text editor or an external diff tool? Jun 13, 2012 at 22:39 -
15@Bryan: Of course it violates DRY.
abstract class AbstractName? Clearly has "abstract" twice. And if you are not using Intellisense, then that's your problem, everybody else uses sane tools to view code.– DeadMGJun 14, 2012 at 7:12 -
16"Everbody"? Most of the people I know use emacs and vi, with a few who use eclipse. Saying something is "your problem" isn't exactly the definition of teamwork. My poorlyl made point was, you can't just set a blanket rule and say that's how it's done. Different teams have different requirements, and not everybody needs assistance with intellisense. Plus, as I said, there are many times when you're looking at code in some tool other than your primary editor or IDE. Jun 14, 2012 at 10:55
-
3+1 definitely violates DRY. Relying on Intellisense is a bit strong, but anyone using the base class should at least look to see what they're extending as part of SOLID.– GaryJun 14, 2012 at 12:21
-
9@BryanOakley why not also put public and final as well? A class name would then look like PublicAbstractPersonThatImplementsInterfaceHuman. Hmm, not quite sure that's good. But I agree, there is nothing such as a universal convention -- use whatever increases the team's collective productivity.– ApoorvJun 15, 2012 at 8:01
In .NET, the use of "Base" as a suffix to denote an abstract base class is often seen. I would defer to the other answers as to whether this is common practice in Java.
-
1+1 for "Base" and "Impl" suffixes. They make a structural point (an abstract class will be the base for something).– vskiJun 13, 2012 at 20:18
-
8@vski: no, I strongly disagree: they're a useless pain in the butt. It's generally perfectly fine to name your interface or base classe with a generic name describe the interface, and your concrete implementation with more expliit names.– haylemJun 13, 2012 at 20:56
-
3I tend to use ...Base for a base class behind an interface. The good name is already taken by the interface, and the base class isn't used anyway by client code.– starblueJun 13, 2012 at 21:30
-
1@Haylem many java design patterns use interfaces with only one expected implementation. Impl is a very useful suffix in these cases.– funkybroJun 13, 2012 at 23:31
-
1@funkybro: That doesn't make it right. it just means that you either didn't need the interface, or that eventually later on other concrete implementations might come. So it's brainless either way. As pointed out just above by Gary Rowe, Default as at least a much more sensible name, which provides some context and meaning.– haylemJun 15, 2012 at 15:08
This is somewhat a matter of preference (but borderline bad practice), but most people don't like seeing part of the qualifiers in the name of the class.
Most IDE's will make that information easily available to you anyway, so putting it in the name isn't necessary, and it will be cleaner to just omit it. It's reminiscent of hungarian notation for variable naming, and that's certainly considered bad form now-a-days. I recommend simply calling it Task.
In my opinion, an entity's name shouldn't convey information about its type structure, but about its semantics. So it doesn't make sense to define your class as "AbstractSomething" if the abstraction is not part of its runtime goal. That it is a base abstract class is visible for the programmer, and doesn't need to be reflected in the name.
However, if makes perfect to call an implementation of an abstract factory an AbstractFactory, because that does relate to the class's intent.
In general, favor naming convention that help to convey the most information about the goal of your class.
Similarly, stay clear from SomethingImpl. We don't care that it's an implementation and not a base class. If your class hierarchy is designed properly for inheritance, then someone could inherit from it. Surely there would be no value in them adding more "Impl" suffixes or other artifacts. There's also no value in adding an "Interface" suffix or "I" prefix.
Consider:
IVehicle <-- IMotoredVehicle <-- AbstractCar <-- CarImpl
As opposed to:
Vehicle <-- MotoredVehicle <-- Car <-- DefaultCar
<-- Ferrari
<-- Trabi
I prefer the latter by far.
This, in some respect, similar to the blatant misuse of the Hungarian Notation that latter gave it its bad rep, as people wrongly started to interpret it as requiring developers to prefix their variables with an indicator of the variable's type. While this can sometimes have its uses (mostly if you are lazy to look up the type's definition), it's mostly useless. Simonyi's original idea with the Hungarian Notation was to use it as a mnemonic to remind the developer of the entity's capabilities, not of its type.
-
Totally agree, as class are concepts putting an implementation notion into its name is something we should avoid till we use it. We dont need either an interface or abstract class, but objects coming from human concepts. Maybe in the conjunction within the lack of multiple inheritence for languages that have interfaces when you need it the I prefix can act as a warning though... Aug 30, 2022 at 21:20
-
Haylem, suppose
Vehicledid not exist, and instead our top-level interface is justCar. We also have concrete implementationsDefaultCarandFerrari. Suppose we had a middle-level abstract class in-between, that implements a couple of traits of a car; say the ability to honk and pull a handbrake, and maybe some other things. What would you call this class? May 7, 2023 at 4:30 -
I think it may also be a challenge to find a replacement for Java's
AbstractMap,AbstractSetandAbstractList. I think that sometimes, the "Abstract" prefix conveys useful information, at the same time not having it may be misleading. For example, having anabstract class SomethingTest. Don't get me wrong Haylem, I think the same way you do. It's just that it seems like some times it appears we have to bend our purist rules a little bit? 🤔 And if the code base has just one of these occurrences, then the "Abstract" naming convention should be applied for the whole project. May 7, 2023 at 5:09 -
We should also note that "Abstract" rarely leak into the public API, so to speak, but rather, it is contained within the inheritance hierarchy of a class. It would be uncommon for an abstract class to be declared as the type of a field, local variable, or method parameter. I would even speculate that most abstract classes are package-private 🤔 So then, one can argue that the "Abstract" prefix functions more as a discovery mechanism for authors writing new classes, as opposed to developers using public types? May 7, 2023 at 5:20
-
A good rule of thumb is to not include properties in a name that are obvious from the syntax. Since in Java, you need to mark an abstract class with the aptly named abstract keyword, I would not include it in the name. In C++, for example, the case is not so clear cut, but at least the compiler will tell you when you incorrectly used an abstract class. In something like Python again, explicitly naming an abstract class as such is not a bad idea.
The usual exception to the rule is when the name is ambiguous. If, for whatever reason, there is a concrete subclass Task (in other examples, this may be more sensible, but whatever), then sure, use AbstractTask.
answered Jun 13, 2012 at 18:36
-
... or an interface such as
Listand theAbstractListclass (which implements it).– user40980Aug 25, 2015 at 21:36
protected abstract SomeClass { }
This tells me this is an Abstract class. Adding a prefix is a tautology and anti-pattern and not appropriate in most cases, see the link where it talks about package local being an exception for example.
In most cases Abstract classes shouldn't be part of a public facing API, if it is there should really be a good reason and a good reason should provide an obviously good name other than AbstractSomeClass.
In most cases if you can't come up with a more descriptive name you probably need to do some redesign.
My five cents, Probably you'll have implementations of that abstract class and they will be named 'SomeSpecificTask', 'TaskWithBubbles', 'StrangeTask' etc. So there won't be a name clash between your abstract 'Task' and them.
Additionally, 'abstract' word is about language syntax, not business domain entities, so I'd prefer not to use it as a part of the name.
On the other hand, in one answer here I saw excerpt from J.Bloch Effective Java which says that using 'abstract' as a part of a name is a well-established practice. It may be so. But anyway in official java code conventions there is nothing about that.
-
public abstract class AbstractList<E> extends AbstractCollection<E> implements List<E>- one can't useListas the name for theAbstractListclass because that is the name of the interface. It is a well established practice and part of the official Java code that is in use where something that implements the interface may or may not extend an abstract class (that also implements (some of) the interface).– user40980Aug 25, 2015 at 21:34
If you work in a team, then entire team must decide whether you should prefix abstract classes with "Abstract".
If you work on your own, then it's entirely up to you, not me or anybody else on this site.
I have done this. I did add 'Abstract' as prefix to my abstract class named AbstractOperation. The reason I did this was there was another package that had a non abstract class named Operation, and It helped my team and the programmers who took over later in avoiding any confusion between the two.
I'm not a Java developer (INAJD?) and don't know the standard nomenclature for such things, but I think Task sounds abstract enough that it can stand alone as-is.
answered Jun 13, 2012 at 18:34
What if you want to write an abstract AbstractSyntaxTree class? Or perhaps just an abstract SyntaxTree?
It's not conventional and it can easily confuse people.
