March 24, 2004
Thoughts on Class Naming
I've noticed that I often include redundant information in my class naming schemes and have been meaning to re-evaluate if and when its really neccessary.
For example the following classes are typical of how I name things:
com.versionary.struts.actions.ViewProductAction
com.versionary.struts.forms.ProductForm
com.versionary.beans.ProductBean
com.versionary.dao.ProductDAO
com.versionary.services.ProductService
Is it really neccessary to append this sort of "metainformation" to the class name when it is obvious they are such things based on the package they belong to?
Isn't that the whole reason why there are packages to avoid naming collision? It seems like in the purest sense they should all be named Product and let the object instance name do all work resolving this supplementary information for the developers reference. Well in practice it really doesnt work out that way it seems.
The only way I can explain the need for this sort of redundant description in the class name is in the following case I use a ProductDAO,ProductBean, ProductService and ProductForm in the ViewProductAction, which is often the case for me at least. The big advantage is I don't have to fully qualify to resolve each of them, which seems to be important, though I don't know how this became ingrained in me. Is this a holdout from our programming heritage, ingrained in our psyche? Why is a FQN so ugly to us but a long class not?
At all costs we avoid dealing with fully qualifying a class and consequently we are overly descriptive in our class naming. I wonder why we all think like this. In an extreme way it kind of makes you question the point of even having an actions,forms,beans,dao and services package other than for appearances and habit if I'm just going to append this sort of information to the class name anyway. With a naming convention like this every class can happily reside in one application package with no problems. I'm not suggesting any of this single global package is something I'd ever do, but I'm just thinking it really wouldn't make a difference if I did.
Perhaps I'm thinking about things incorrectly. Maybe this sort of naming is a neccessary redundancy for the sake of a greater simplification i.e. avoiding fully qualifying. I was going through various example/sample projects out there just to see how other people do their naming. For struts and ww, every piece of Action code I've ever come across always appends Action to the class name. This seems to be a standard practice even though the chances of the developer actually referencing this class anywhere outside the configuration file is usually very slim so the fully qualifying argument doesnt really apply here yet we all still do it.
On another front the Spring framework's jpetstore app and some recent purchases have left me thinking that maybe what I've been calling beans are in most cases more appropriately called domain objects. It seems that in the Spring code domain objects receive a naming preference in the application and go unappended while other potentially ambiguous classes have their secondary information added to them. This seems pretty reasonable to me, especially since I was not giving any class this distinction previously.
Now the question becomes is it really simpler to "pollute" the class name with this information or fullly qualify to avoid it.
I'm probably going to stick with how I've been doing things except shift to giving my bean/domain objects preference to the "unpolluted" name for now and think a little more about it.
Posted by
Andre Mermegas
at
March 24, 2004 07:28 PM
|
TrackBack
I see your point, and think it is valid, however, I find myself using similar naming schemes both in my personal work and the stuff I do at my job. Although not as finely grained as what you have, we seperate our packages into .bus, .db, and .vo for business layers, data access layers (mostly for stateless session beans), and value objects. This, however, is crossover from the days of programming in VB 6 at work and the desire to keep things standard.
I have seen documentation from sun with the following naming standards for beans
Bean Bean
Remote Interface
Home Interface Home
Local Interface Local
Local Home Int LocalHome
etc etc etc...
I would personally stick with what you refer to as "polluted" naming schemes to avoid the need to use FQN all over the place in code.
Hi,
I personally think that these redundant information in class naming schemes doesn't make any sense anymore. Before the "Eclipse-Age" it could have made sense to name the classes differently because otherwise "grep"
would not work very well.
Regards,
Markus
Hi!
I am of the opinion that the naming conventions you use are useful. If everything was product, you would have to reference everything with their package names prepended
e.g.
Form newForm = com.versionary.struts.forms.Product;
Also, it is easier to communicate with the conventions.
My .02!
Nice blog, just wanted to say I found you through Google
