code_poet writes about it class naming conventions. I’d like to submit my own.
Interfaces
Interfaces are named after the Business Objects that it defines, the Party, Thing, Service or the like.
Examples:
- 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.
AbstractImplementations
For abstract classes that might implement an interface I use AbstractXXX.
Examples:
- 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.
Examples:
- 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.
Examples:
- 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.
Examples:
- 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.
Exmples:
- MapUtils, ListUtils
- JTableUtils
- HibernateUtils
0 Responses to “My Class naming conventions”