Should I add an “Abstract” prefix to my abstract classes?

Question

Suppose I have an abstract class named Task.

Is there a standard or convention that would suggest I should name it AbstractTask instead?

Answer 1

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.

Answer 2

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).

Answer 3

No. Intellisense will trivially tell me if it is abstract, so you're just violating DRY here.

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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.

Answer 8

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.

Answer 9

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.

Answer 10

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.

Answer 11

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.

Answer 12

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.

Answer 13

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.