Are Naming Conventions Still Needed For Abstract Classes?
In case you have trouble to find a unique name for an abstract class, you probably don't need it. Some reasons, why "Abstract" doesn't have to appear as prefix in the name of an abstract class:
- 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 intension.
- Modern IDEs don't let you instantiate an abstract class, even before saving / compiling.
- If you really have to, it is easy to find / distinguish an abstract class with modern IDEs.
- Even in UML class diagrams abstract classes are easy to distinguish - their name is italicized.
The naming conventions for abstract classes are as superfluous as for interfaces.
One of the things I try do is to design from interfaces and extend from abstract classes if needed.
So List is the interface and AbstractList abstract implementation that can be extended for boilerplate code.
Imho abstract still has a value as naming convention.
Posted by Peter Veentjer on September 14, 2009 at 12:36 PM CEST #
But: what is the intention in your approach? Wouldn't an abstract class only be enough in your case?
I guess it should be possible to name the abstract class after its responsibilities. There should be a reason to introduce it.
thanks for your feedback!,
regards,
adam
Posted by Adam Bien on September 14, 2009 at 01:06 PM CEST #
Also, the code may evolve and you may want to change the class from being abstract to non-abstract. To be consistent you will then have to rename the class (omit the "abstract" from its name) which is not always trivial, esp. if the class is part of a published interface
Posted by Itay Maman on September 14, 2009 at 02:15 PM CEST #
When the 'abstract' class is the base of the class hierarchy, I agree that adding the prefix Abstract is not very useful.
Posted by Peter Veentjer on September 14, 2009 at 03:10 PM CEST #
I would say it depends whether it is
- A domain object (Entity): Truck extends AbstractVehicle is ugly and useless
- A technical base class: TruckDAO extends AbstractDAO or DefaultTableModel extends AbstractTableModel doesn't shock me
Posted by Gérald Quintana on September 15, 2009 at 12:49 AM CEST #
@Gerald,
why not TruckDAO extends DAO and DefaultTableModel extends TableModel?
The prefix "Abstract" doesn't provide any additional information.
It isn't a problem - its just superfluous,
thanks for your comment!,
adam
Posted by Adam Bien on September 15, 2009 at 10:59 AM CEST #
I agree with you. It is unnessesary to name an abstract class Abstract...
Posted by Martin Krüger on September 15, 2009 at 01:40 PM CEST #
Often enough there are different types that deserve the same name.
For good reasons the TableModel is an interface (and has no prefix on its name).
The AbstractTableModel provides helpful methods that are common to different implementation - but due to the programming against the interface they are not needed to be used (which is often enough the case). The DefaultTableModel is a base implementation that can be used out of the box.
The abstract class AbstractTableModel provides a lot of convenience above the TableModel when implementing an own model.
This set of types - interface, abstract implementing convenience class, default implementation - is very helpful.
The name AbstractTableModel seems appropriate. It is exactly that: A partly implemented (thus abstract) table model.
Posted by Hauke Ingmar on September 15, 2009 at 01:55 PM CEST #
I use abstract to help me with my IDE. I think the main reason that I prefix with Abstract is that when I hit the keys to goto class, or open resource, and I know I am looking for an abstract class, I type Abstract and see my list. Although this particular project has 22 modules and hundreds of classes so I am likely to not know what I am looking for until I see the list.
Posted by Mike on September 15, 2009 at 05:40 PM CEST #
@Hauke,
I understand your point. In my past projects I prefixed generated classes with "Abstract" (they were actually abstract) and had to inherit from them. The prefix "Generated" would be even better.
AbstractTableModel provides convenience methods - so a ConvenientTableModel should be a better name :-). GenericTableModel would work either.
The example, however, isn't a good one, because the target domain is technical - its a UI framework. In business applications the naming should be more clear...
thanks!,
adam
Posted by Adam Bien on September 15, 2009 at 06:01 PM CEST #
@Mike,
got it - but an IDE-filter (which hides abstract classes) would work as well in your case, right?
thanks!,
adam
Posted by Adam Bien on September 15, 2009 at 06:02 PM CEST #
1) For some use cases there is a need to distinguish an abstract class from non-abstract via its name. In standard Javadocs, when you are looking at a list of classes, there is nothing that indicates a given class is abstract like there is for an interface. Moreover, the 'abstract' qualifier does not stand out like the name.
As far as I can see, at least in the *default* configuration, neither Netbeans nor Eclipse will *not* show you at a glance of a class list/tree, whether a class is abstract or not without opening it in an editor. Ditto with interfaces. I see no differentiation in font style, icon, color or any other indicator.
Maybe IntelliJ is smarter. Maybe there is a plugin for NB/Eclipse, or some non-default configuration setting to show this.
2) The intention seems pretty clear to me - it is the base implementation class, usually of an interface, that needs one or more methods to be implemented by a 'concrete' class. I am very used to the pattern of interface, abstract, default, specific. It is used throughout the Java world and has value IMO. I can quickly look at a framework/API and find which level class I wish to work with. If I have to open the Javadocs (or worse, the class in an IDE) for each class to find which is (if any), the abstract base class, then it takes longer. Therefore it is not irrelevant or superfluous.
Posted by Developer Dude on September 15, 2009 at 09:00 PM CEST #
1) At the call site, you don't see the "abstract" keyword, so having Abstract in the class name is useful.
2) "Abstract" makes it clear to the user they can't 'new' the class. Same reasoning for interfaces.
3) doesn't have any connection with your topic
4) You have to interact with the source (mouse, keyboard) to find out if a class is abstract. If you use a keyword like "Abstract" in the class name, just reading the code will provide the information you need
5) doesn't solve the problem of source code understanding
Please use "Abstract" (or any other convention) to name your abstract classes, readers of your source code will thank you.
Posted by Cedric on September 16, 2009 at 09:12 PM CEST #
It depends on the intended use of the class.
As stated by you, it fits better technical frameworks. In domain code, it generally doesn't look good, as it probably won't map to any business concept. Not that it is really required, but often it doesn't make sense to have this Abstract class, or it could be named better.
And, as stated by others, it's very useful when you have the 'interface -> abstract -> default -> specific' pattern.
But, in cases where you use these classes directly in your application code, maybe it's better to omit the 'Abstract' prefix.
For example, when using Wicket, one would usually use the class Link directly, implementing the 'onClick()' method inline, as an anonymous inner class. In this case, the 'Abstract' prefix would just add noise to the code. Well, there is an AbstractLink class, too, which fits the 'base implementation' role, but Link is also an abstract class, and is the one you usually use in your code.
Posted by Tetsuo on September 16, 2009 at 09:41 PM CEST #
I agree that there are different naming requirements for business and for framework code. There should be no need for a name with "Abstract" in business code.
For framework code it is a good and helpful convention to have interface -> abstract -> default. As the interface defines the type that the other code will work on it should not have any additional identifying parts (like prepended "I").
(I don't agree with your other suggestions for the abstract class' naming but I don't think it is very helpful to discuss that ;-)).
Posted by Hauke Ingmar on September 18, 2009 at 08:04 PM CEST #
I'm of the old school which believed that the more information the better, including one's intention. So I preface my interfaces with an I and my abstractlasses with Abstract when I believe that doing so provides necessary information regarding the intention of a class or interface.
Jeff
http://jeff-schwartz.blogspot.com/
Posted by Jeff Schwartz on October 21, 2009 at 04:00 AM CEST #
A good case against using the Abstract prefix is that one would typically use abstract classes to program to an interface instead of an implementation, but by adding the Abstract prefix to a classname you're (ironically?) adding implementation details to the interface. Like Adam said; what about changing your class to not be abstract anymore? You would have to change the name everywhere in your code.
Thanks for the post. It helped me make up my mind about this.
Posted by Adaptor on September 03, 2011 at 06:10 PM CEST #