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”.

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:

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.

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.