2

Background:
I have a rough, but working understanding of ~15 design patterns. It's been my experience using design patterns in my own projects that the resulting implementations usually end up as some variant of a pattern and don't always fit the canonical textbook examples.

Case:
I find it useful to leave tag-like comments that hint at an underlying archetype, e.g., in the following Javadoc class description, the "[Singleton]" label is used merely to describe that there's only one of these objects used at any given time. This class may or may not be set up to "restrict the instantiation of a class to one object" --Wikipedia.

/** * [Singleton] * The manager of all jewels, which are stored here in collections. */ public class JewelManager implements IDestroyable {

Context:
I'm working on a team with several other developers, but I need to assume there may be other devs working on the project with whom I will never have the opportunity to speak.

Question:
Is it misleading to label classes or methods as a particular design pattern (Strategy, Mediator, etc.) if they only loosely fit that definition?

Improve this question
6
  • Mostly people implement slight-variations of design patterns. Like trying to reuse someone else's code; it always seems like what is defined "almost" does what you want but not exactly, so you end up having to tailor it to suit your needs. I think if you can see where it may be confusing then you should add a little comment with clarifications. If it should be obvious then don't worry about it because most developers already know that your implementation is probably a slight variation. Commented Dec 15, 2014 at 16:44
  • To begin with, try summarize each pattern in your own words. Sometimes your summary is even more understandable than the original pattern name. Say, in your example it is might have been a static instance (if it actually is). See how simple it is? Commented Dec 15, 2014 at 20:50
  • The claim that naming a pattern can greatly enhance the brevity of communication is extremely exaggerated. Most of the time, the mentioning of a pattern in source code is the case of a "Koan", meaning: if you don't comprehend the code below, try read about that pattern, and when you come back you'll understand. Commented Dec 15, 2014 at 20:53
  • @Dunk: I think it's the opposite. Most people write code to solve problems (often without caring about design patterns and sometimes without knowing about design patterns at all), and design patterns were created by finding things that were common in very different pieces of code (in the same way that people see shapes like faces, elephants, cats when they see clouds, or decide a pattern of stars looks a bit like a saucepan). Commented Dec 16, 2014 at 7:40
  • @Brendan:I agree most people don't use design patterns at all, but not because they are great at coming up with ideas of their own to solve problems but instead because software design is hard; so it is much easier to wing-it than to transition to being an expert in their trade as opposed to being a code monkey. My comment was in respect to people who have some knowledge of design patterns. Otherwise, using the design pattern name won't mean anything to them anyways. Commented Dec 19, 2014 at 18:27

3 Answers 3

Reset to default
5

Is it misleading to label classes or methods as a particular design pattern (Strategy, Mediator, etc.) if they only loosely fit that definition?

It depends.

If you have a singleton and it does not prevent instantiation, then it would be misleading to label it a singleton, since it's not a singleton. It's a global variable. Doing otherwise leads your fellow developers to make (reasonable) assumptions, which will be wrong, which will lead to subtle, catastrophic errors.

If you have say... a factory that returns new random objects rather than new objects based on the input to the factory. It's probably okay to call that a factory. Your fellow programmers shouldn't know (or care) about its implementation details. And that new implementation, while not a factory per se, does not break the implied contract of a factory: "you give me X and I will give you a new Y".

Improve this answer
3
  • 1
    Exactly, design-patterns are also a great tool because they make communication with other devs easier. If you explain to me that you used pattern X somewhere, and it behaves exactly like pattern X even though there are minor difference in the implementation, that doesn't matter to me, the one using it. Commented Dec 13, 2014 at 17:21
  • Perhaps another factor being the name of the pattern you're using? A word like "factory" already has a very software-friendly meaning outside of the Factory Pattern: A thing that makes things. Commented Dec 13, 2014 at 20:55
  • @pup - No. Unless you're working in the civil engineering domain, if you refer to something as a "bridge" I expect the pattern. Same with adapter, strategy, whatever. Commented Dec 13, 2014 at 20:59
2

Labeling a pattern as [X] in Javadoc is really not so useful. Too many patterns are mis-applied because developers don't validate the patterns' assumptions (which are also not documented).

Your Singleton example is trivial, as Singleton is more of an idiom than a design pattern.

There's at least one project (http://www.jpatterns.org/) that uses Javadoc annotations for labeling elements of a design pattern in Java. See https://stackoverflow.com/q/127411/1168342

I'd argue that pattern application requires not just labels/annotations of the elements (the what), but also justifications with assumptions (the why).

Consider Visitor:

Visitor pattern

Labels should be applied to the classes in the Element hierarchy (Element at least) as well as the Visitor hierarchy (not so needed if you use the word Visitor in the pattern).

Assumptions (which could be documented in the Visitor interface, I suppose):

  • The Element hierarchy is expected not to evolve (else your Visitors will all need changing).
  • The Visitor hierarchy is expected to get new ConcreteVisitors in the future (which justifies the complexity of Visitor).

If you only have one ConcreteVisitor, then it could be hard to justify the complexity of double-dispatch (which affects performance and makes the code harder to debug). Most all design patterns are investments in complexity which should pay off if your assumptions are correct (e.g., Visitor is worth it if you need to add new functionality and your Element structure is stable). Break these assumptions and it may be a bad design finally.

Sadly, many of the wiki pages on patterns don't mention these strengths/weaknesses. Return to the GoF references or a good book on patterns for the details.

Improve this answer
1

Is it misleading to label classes or methods as a particular design pattern (Strategy, Mediator, etc.) if they only loosely fit that definition?

No, it is not misleading; rather it should not be.

  1. Too Loose Obstructs Understanding. If we say a global read only variable is a singleton, that's not "loose" that's just wrong. Besides, strictly speaking a "singleton" is how the object is constructed; that object could very well be one of the structural patterns.
  2. Modern language constructs can let us adhere to the intent of a given design pattern but deviate from the classical class model as seen in the GoF book. For example in the Command Pattern, concrete commands are subclasses (or implement an interface). However one could use a delegate for the "command method" without subclassing. The command pattern goal is met: decoupling the requester from the execution of the request.
  3. Intent matters. There is similarity between some patterns but the slight, seemingly pointless, differentiation expresses intent of the pattern. For example look at the striking similarity between the Composite and Decorator patterns.
  4. Specificity. For example it is not enough to say "factory". "Factory Method", "Factory class", and "Abstract Factory" each express increasingly complex solutions to the general idea of separating object construction from its use. Then consider the Builder pattern which could be described as a flexible Abstract Factory.
Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.