Tuesday, March 20, 2007

Strategy

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: