Just how important are naming conventions when it comes to OO design ? I was thinking of conversion projects where MVC may not be fully MVC because of some underlying characteristic of the existing environment that needs preserving. Should you still aim for a MVC design and just get the redundant bits to do nothing ? [ January 26, 2004: Message edited by: HS Thomas ]
Naming is an important aspect of a system's maintainability and affects how well your models communicate. Regarding the MVC stuff, I would prefer not having classes with no behavior at all. It's clutter which slows you down and isn't too costly to re-create if a need arises.
Having a consistent naming policy is IMO more important than what that policy actually is. Of course when using a 3rd party API it's always best to stick close to what that API uses in order to avoid confusion (which can be troublesome when using several APIs together that have clashing ideas about how things should be called).
When naming is generally consistent throughout the system under development and isn't too far off the mark, then no-one really notices anything, because everything's pretty much just fine. However, when naming fails, it can really really be a big crimp in understanding. The project I came into six months ago had a whole bunch of classes called FooWrapperBean. On a cursory first browse through the code, it looked like they were stateless EJB session facades providing a service layer on top of a lower-level layer of other EJBs. Turns out that they were actually just POJOs that caught and then threw away the RemoteExceptions involved in the EJB calls (no logging, nothing, just a comment saying "can be ignored, doesn't need to be logged") so that the application layer (servlets) didn't need to bother with them. Caused a whole lot of misunderstandings and headaches. Needless to say, they've been renamed. All hail Eclipse and Alt-Shift-R.
I love a good mentalist. And so does this tiny ad:
Devious Experiments for a Truly Passive Greenhouse!