jQuery in Action, 2nd edition*
The moose likes OO, Patterns, UML and Refactoring and the fly likes Design patterns and class naming Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Design patterns and class naming" Watch "Design patterns and class naming" New topic
Author

Design patterns and class naming

Raf Szczypiorski
Ranch Hand

Joined: Aug 21, 2008
Posts: 383
Hi. I have been curious about the usage on patterns and its influence on class naming. Is it always a good thing to name classes that are modeled after a pattern using the naming convention of a pattern?
For example, the other day I have been working with the Visitor pattern, but the actual class name that would fit best into the domain I was applying it to would be like 'Algorightm' or 'Operation', accept() (on Visitable, which has a different name in my case anyways - Operand) would be 'apply()', and Visitor.visit() would be Operation / Algorithm.apply(Operand).
On the one hand, different names would fit better in to domain model. On the other hand, when anyone comes and has to maintain the code, and I use Visitor, accept, visit and so on, it is immediately clear what pattern it is. But this information can be put in the documentation (JavaDoc or whatever).
What do you think?

Raf
Ryan McGuire
Ranch Hand

Joined: Feb 18, 2005
Posts: 1012
    
    3
Raf Szczypiorski wrote:Hi. I have been curious about the usage on patterns and its influence on class naming. Is it always a good thing to name classes that are modeled after a pattern using the naming convention of a pattern?
For example, the other day I have been working with the Visitor pattern, but the actual class name that would fit best into the domain I was applying it to would be like 'Algorightm' or 'Operation', accept() (on Visitable, which has a different name in my case anyways - Operand) would be 'apply()', and Visitor.visit() would be Operation / Algorithm.apply(Operand).
On the one hand, different names would fit better in to domain model. On the other hand, when anyone comes and has to maintain the code, and I use Visitor, accept, visit and so on, it is immediately clear what pattern it is. But this information can be put in the documentation (JavaDoc or whatever).
What do you think?

Raf


What are the possibilities:

1. Completely use the class names described int he pattern. That's prevents the possibility of having multiple instances of the same pattern so this option is out.

2. Use class names that are a hybrid of your domain and the standard pattern: class AlgorithmVisitor, OperatndVisitable.applyVisit(). This is doable, but unnecessarily verbose.

3. Use class names from your own domain, but then comment the code.
// This method is analogous to the Visited.visit() method as described in the Visitor pattern.
public void apply() {

4. Silently use the names from your own domain:
public void apply() {


I personally go with option 3 as much as possible and slip into using option 4 either when I'm pressed for time or when the role of the class is obvious.

Raf Szczypiorski
Ranch Hand

Joined: Aug 21, 2008
Posts: 383
Thank you for your answer. I knew of the options you listed, and after giving it some thought, I also went for option 3 (actually it is a hybrid of option 3 and 4 - documentation and comments will come a little later - time pressure).
I considered and even coded with what you list as option 2, but this was so clumsy and ridiculous in my domain that I gave it up real quick. After all, the class / method names are important as well, quite a lot, I would even say.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Design patterns and class naming