Design Patterns: Boondoggle or State-of-the-Art?

Here's a nice little tutorial on them if anyone is interested...

http://www.csc.calpoly.edu/~dbutler/tutorials/winter96/patterns/

thank you for directing the focus on the important topic of design patterns. With about ten years of research I would not really consider this a "new" topic.

If you sail on the large ocean of software at SAP, you will surely find islands populated by the various design patterns.

Let's take a look at the Web Dynpro UI Element library named "Core".

The "Core" library is the foundation of all existing and future Web Dynpro UI element libraries because it provides the base classes/interfaces that all other library elements must extend/implement.

Being a very small island with only 6 inhabitants I think it is nevertheless an interesting place.

The inhabitants are called "ViewElement", "UIElement", "UIElementContainer", "Layout", "LayoutData" and "Visibility".

What are their roles?

ViewElement represents an abstraction for an "adressable thing living in a view". So it provides an identifier and holds a reference to its containing view. The view itself stores a map of all its view elements such that one can efficiently find each view element by its identifier.

UIElement is a subclass of ViewElement augmenting it with some common properties, namely "enabled", "visible" and "tooltip". Their meaning should be obvious.

UIElementContainer is a subclass of UIElement adding the properties "width" and "height".

To be able to create containment hierarchies, UIElementContainer provides a (bidirectional) aggregation to class UIElement named "Children". Because UIElementContainer is a subclass of UIElement, one can nest UIElementContainers into each other and create arbitrary deep containment hierarchies.

Here you have the Pattern 1: "Composite"

The "children" of a UI element container may be traversed without knowing the internal storage data structure. To allow this, UIElementContainer provides a method iterateChildren() that returns an iterator object.

So we get Pattern 2: "Iterator"

The children of a UIElementContainer can be rendered in a number of predefined ways. So you need a "strategy" of how to achieve this:

Each UIElementContainer aggregates a Layout object whose implementation defines the algorithm used to layo out the container's children. In general, a child managed my a certain layout, must store some LayoutData, e.g. a position in a coordinate system.

During runtime, the application can change the layout of a container by setting a different Layout object and providing the children with the corresponding layout data.

So we get Pattern 3: "Strategy"

A Web Dynpro application is completely shielded from the implementation classes of UI element libraries. To achieve this, each library element provides a public interface, these IWD-things like IWDButton. One might consider this as a very simple case of

Pattern 4: "Facade"

But if you can only see interfaces of UI elements, how can you create instances? You cannot use the "new"-Operator because the implementation class is not visible to the application. What you need here, is

Pattern 5: "Factory"

In the current Web Dynpro Java Runtime, we use the  view as a generic factory. That means you pass the public interface of a UI element to a factory method together with an identifier, and you get an instance of the implementation class.

Example: How to create a button with ID "buzzer"?

IWDButton buzzer = (IWDButton)
  view.createElement(IWDButton.class, "buzzer");

Let's stop here, perhaps one should better write a Weblog about this topic.

My point is:

If you *design* a set of collaborating classes, you naturally come in touch with the basic design patterns.

But this does not happen automatically. You must *know* about patterns, must *think* in terms of them and must *play* with variants of them to really get a benefit, IMHO.

Armin Reichert