Home > java > Response: Are Naming Conventions Still Needed For Abstract Classes?

Response: Are Naming Conventions Still Needed For Abstract Classes?

September 16th, 2009 Leave a comment Go to comments

I came across a post on the Adam Bien blog recently about using the prefix ‘Abstract‘ to define Abstract classes. The argument was that using the ‘Abstract‘ prefix is superfluous. I do not fully agree with the post. As I read the points he had mentioned on the post, here are some that came to mind

Abstract classes are already distinguishable by the keyword abstract. There is no need to further emphasize it.

A prefix “Abstract” doesn’t provide any additional value to the user – in contrary it blurs the actual intention

The Abstract in the class name helps a developer know that a class is Abstract even before they open it. Of course if some one bucks the convention and names a Concrete class abstract, it creates confusion but that scenario is rare.

Modern IDEs don’t let you instantiate an abstract class, even before saving / compiling.

The IDE would not let you instantiate the class whether or not the Abstract prefix is placed on the class name. If Abstract is used as a prefix, a developer would know before hand that the class is abstract.

If you really have to, it is easy to find / distinguish an abstract class with modern IDEs.

An IDE should be able to give you such a filter, but I wonder if it is a common feature across IDEs. I am not aware of a shortcut in eclipse that can do this (it might exist, I am just not aware of one). When I want to open an Abstract class, I type ctrl+shift+R and type ‘abstract’. That usually yields good results.

Even in UML class diagrams abstract classes are easy to distinguish – their name is italicized.

This is true. If you name your class AbstractSomething just because you want to distinguish them in UML diagrams, it is not justifiable.

So what good does an Abstract prefix do for a class ? Here is my opinion

  1. Developers know a class is Abstract without opening it.
  2. The name helps the developer realize that the class is meant to be inherited by a subclass, which will provide methods that the boiler plate does not.
  3. Provides a developer one more way to search for Abstract classes.

In summary I would say that whether or not you want to use the Abstract prefix depends. Most boiler plate classes that you encounter (non abstract) use the word Default as a prefix. Example – DefaultContentHandler. Boiler plate code with some abstract methods use the word ‘Abstract’ as a prefix. Example – AbstractList. There are classes that do not follow the convention, but I would still vote for the word Abstract as a prefix because of the advantages that it presents.




Categories: java Tags: ,
  1. September 16th, 2009 at 18:06 | #1

    You make some good points here. I wonder, though: what if we applied the same arguments to interfaces — would it make any more sense if it was ‘ListInterface’ instead of just ‘List’?

  2. September 17th, 2009 at 03:59 | #2

    @Jeff
    That is a good point Jeff. There are Interfaces that buck naming conventions too. While deciding on a name for an interface, the suggestion is usually to make it verb like. For example – Runnable, Serializable or to prefix it with ‘I’ or ‘IF’. There are interfaces that do not follow the convention, like List, Set, Map etc.

    I guess the argument can be extended to interfaces as well. In fact I found a similar post on Adam’s blog about interfaces -> http://www.adam-bien.com/roller/abien/entry/in_the_age_of_dryness

  3. raveman
    September 18th, 2009 at 12:06 | #3

    You can use eclipse name convention(check out the source code) and interfaces have I prefix. It hurts no1 and helps a lot of people.

  4. September 18th, 2009 at 13:57 | #4

    @raveman
    Agreed. The same argument does extend to Abstract and Interface.

  5. Hauke Ingmar
    September 18th, 2009 at 15:43 | #5

    I do not agree. Interfaces describe a type – a List implementation IS a List. It’s the type List that is always worked on. An interface identifier would tell nothing useful; the knowledge of working against an interface instead of working against any other type information doesn’t change how the object is used.
    This is different with abstract classes. Abstract classes have to be extended to be useful. Sure, this information is covered with the “abstract” keyword. But the class has to be found. The “Abstract” naming convention helps (and “Default…”; see the comments to Adam’s post for this).
    The “Abstract” naming convention should be noticed by the developer only sparsely – in fact only in the beginning of a project when the business specific subclasses are created. Afterwards the interfaces should be used for type information, the non-abstract classes for instantiation.

  6. September 18th, 2009 at 16:01 | #6

    @Hauke Ingmar
    Even at a later course in the project an ‘Abstract’ prefixed class might help you when you want to locate the class that has some boiler plate code. If you wanted to say, implement a new type of List, you could either implement List or extend AbstractList.

    An interface identifier might help when you are looking for an interface to implement, just like when you are looking for an Abstract class to extend. An Interface standard which has an ‘I’ prefix is not common in the JDK API, atleast to my knowledge. But I do not have anything against it as such.

    Thank you for sharing your thoughts.

  7. Swati
    November 28th, 2010 at 01:01 | #7

    I want to add one more point to
    “Modern IDEs don’t let you instantiate an abstract class, even before saving / compiling.”
    is
    “Also Eclipse IDE provides an icon(Abstract/Concrete) before class name when Ctrl + space is hit”.

  8. November 19th, 2011 at 08:03 | #8

    I simply wished to say thanks once more. I do not know the things I could possibly have undertaken without the creative concepts documented by you on this theme. It absolutely was the intimidating difficulty in my view, however , encountering a new skilled fashion you treated the issue forced me to weep with joy. I am happier for this work and believe you find out what a powerful job you are always getting into instructing many people all through your website. I’m certain you haven’t encountered all of us.

  1. No trackbacks yet.