Return to Answer

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 http://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.

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.

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 http://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 http://upload.wikimedia.org/wikipedia/commons/9/9d/VisitorDiagram.svg

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.

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 http://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.

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 http://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 http://upload.wikimedia.org/wikipedia/commons/9/9d/VisitorDiagram.svg

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 assumed to not evolve (else your Visitors will 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.

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 http://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 http://upload.wikimedia.org/wikipedia/commons/9/9d/VisitorDiagram.svg

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.