should I name all my abstract classes AbstractFoo

Question

Is it good practice to make sure that all abstract classes have names prefixed with "Abstract"?

Answer 1

You can but I tend not to do this since it is an implementation detail.

I don't like adding implementation detail information in the names of types and identifiers as that kind of information may change in the future. In my opinion it is best to name things what they are, not how they happen to be implemented.

Answer 2

I think this naming convention is just used because it is hard to come up with another good name. If you already have an interface called "List", how would one name the "AbstractList" class? It's more about avoiding name clashes then telling implementation details.

Answer 3

That depends on your coding conventions.

You might also call them FooBase, or just Foo if you don't already have an interface Foo.

Answer 4

If you consider how it is in the .NET framework, no. Take for example the abstract Stream class. Nothing in the class name indicates that it is in fact abstract.

Answer 5

Kinda hard to explain but I only use it to avoid copy/pasting the same code in functional classes and not in something like domain objects.

• AbstractServiceTestCase --> The Abstract prefix seems helpful
• AbstractAnimal --> Seems weird and unhelpful

You should ofcourse decide for yourself, as long as the same convention is followed throughout a project.

Answer 6

I would not call abstract classes Abstract for the following reason:

Every Rectangle is a Shape. Everywhere you can use a Shape, you can use a Rectangle. Code that deals with a Rectangle (but which can also deal with Circles) might look like:

Shape s = .....;
s.drawTo(myGraphicsContext);

Using an object (e.g. a Rectangle) anywhere you can use a generalization of it (e.g. a Shape) is an important part of the object-oriented concept, and known as the Liskov Substitution Principle. (It’s also obvious: what sort of sentence or logic would make statements about shapes, but then not be applicable to rectangles?)

If you name the generalization an AbstractShape, this principle is violated. A Rectangle isn’t an AbstractShape. If anything it’s a “Concrete Shape”! A rectangle isn’t abstract (in the sense of “I don’t know what type of shape this is. Could be a rectangle, could be anything else.”). Code using AbstractShape then reads wrong:

AbstractShape s = new Rectangle(...);

I blogged with more thoughts on this topic here.

Answer 7

I find it useful to name classes in this fashion. It sends a message that they are intended to be sub-classed; not instantiated; contain code common to subclasses, etc.

It's not always necessary though. Most programmers would probably identify "Shape" as an abstract class and "Square", "Circle", etc. as concrete. But if it's not immediately clear, it's a useful hint.

You should also be guided by local programming conventions and style guides.

Answer 8

I think it partly depends on how you will be using the class. If it's only intended for internal use in forcing derived classes to conform to an interface, then adding Abstract before it might not be a bad idea. However, if you are providing a Foo factory that will provide Foo instances that are actually SpecializedFoo1 or SpecializedFoo2, then it seems awkward to return AbstractFoo instances.

Answer 9

The answers so far are very helpful and show a responsible spread of practice. I tend to agree that names should not indicate implementation (Foo could be an abstract class which was later moved to an interface). However it is useful for me when coding to have visual clues that I need to provide methods for derived classes.

As an example I currently have a hieararchy (don't ask about the rationale for the names but they are meaningful in the context and map onto XML element names). I'm using Java but I think most languages would be similar:

public abstract class Marker {...}
public class Template extends Marker {...}
public class Regex extends Marker {...}

I am now tending towards:

public abstract class Marker {...}
public class TemplateMarker extends Marker {...}
public class RegexMarker extends Marker {...}

rather than

public abstract class AbstractMarker {...}
public class Template extends AbstractMarker {...}
public class Regex extends AbstractMarker {...}

or

public abstract class AbstractMarker {...}
public class TemplateMarker extends AbstractMarker {...}
public class RegexMarker extends AbstractMarker {...}

I personally can remember that Marker is an abstract functional concept and that the subclasses are concrete implementations.