Currently I am studying dssign pattern for creating a little ``framework'' for machine learning algorithms. Though it is now too ambitious for me, I decide to learn something through all these failures of designs. Then I happen to find umbrello, a KDE UML designer. I think it is nice even when I can't fully understand it. Here is a diagram exported by it representing the Strategy design pattern.
In the settings above, we want to add a set of typesetting algorithms for composing glyphs. The class(actually an interface)
Compositor contains a pointer to what it is required to compose (which I don't know how to express in the UML), a pointer to an instance of
Composition. The interface has two functions, one for setting the instance, the other for typeseting algorithms which should be realized by its subclasses, such as
ArrayCompositor and
TeXCompositor.
The objects of
Composition contains a
Compositor instance, which is delegated with typesetting work when
Insert() is called. As a result, any new typesetting algorithms can be added as a new subclass of
Compositor.
This pattern solves the problem of tackling the same problem with different strategies. That is, define a strategy interface which is built on whoever needs, realize the concrete algorithms as its subclasses and delegate the procedure to the aggregated strategy objects. Here is a figure to illustrate the role Strategy plays:
