Win a copy of Design for the Mind this week in the Design forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Design patterns and class naming

 
Raf Szczypiorski
Ranch Hand
Posts: 383
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 1057
4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 383
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic