My Class naming conventions

code_poet writes about it class naming conventions. I’d like to submit my own.


Interfaces are named after the Business Objects that it defines, the Party, Thing, Service or the like.


  • Person
  • PersonManager
  • TimeCurrencyConverter

I do not use a “Marker Letter” or any other special convention because I’d like to use a “Person” later on and the code does not care if it’s an Interface or an Implementation the object has to behave like a Person, not a IPerson or PersonIntf.


For abstract classes that might implement an interface I use AbstractXXX.


  • AbstractPerson
  • AbstractPersonDAO
  • AbstractCurrencyConveter

I use the AbstractPrefix to make clear that this class cannot be instanited but the implementation must be “completed” first.

Default Implementations

For the standard or default implementation of an interface or abstract class I use DefaultXXX. This makes clear the the implementation does not depend on any special features like a certain persistence framework, e.g.


  • DefaultCurrencyConverter

JavaBeans and ValueObjects

All those little JavaBeans and value objects I pass around in my business layer are named XXXBean if they follow the Bean specification and do not depend on any special external feature.


  • PersonBean – a in memory implementation of Person
  • CurrencyConverterBean – an implementation of CurrencyConverter that follows the Bean spec.

Implementations that depend on special external features

For classes implementating an interface and that depend on a certain external feature like a persistence framework I use FrameworknameXXXX.


  • HibernatePersonManager
  • HibernateCurrencyConverter

Utilitiy classes

The little hepler classes the contain all the usefull things are name XXXUtil, where XXX is a JDK class, or JDK or external feature it extends or completes.


  • MapUtils, ListUtils
  • JTableUtils
  • HibernateUtils

{ Comments are closed! }