Design patterns as composition operators PDF Print E-mail

It is not an entirely new observation, but not one that is common knowledge, either; many design patterns can be seen as describing the way that two or more objects are composed. As a result, if you are able to capture the knowledge about this compositon in an abstraction (as we are doing now with the Co-op model, and as e.g. been done many times using aspects), the resulting abstraction can be considered as a composition operator.

A composition operator is an explicit abstraction, with its own identity, that can be used for composing program elements (typically objects or classes). Composition operators may be first-class, programmable, abstractions in your system (as in Co-op), but this is not necessarily the case.

Here are a few examples to illustrate the idea:

  • The Strategy pattern (dynamically) composes a Context wiith a Strategy that implements
  • The Observer pattern composes Subjects with Observers, through a specific subscription and notification protocol
  • The Visitor pattern composes a set related operations, encapsulated by a Visitor, with a data structure
  • The Decorator pattern (dynamically) composes Decorators with Components (and with each other)

So, what is the value of this observation? At least two things come to mind:

  • It is possible to describe many design patterns as means to compose objects; this may help to clearly define what exactly defines a design pattern; what belongs to the pattern, and what doesn't. Especially if you are trying to modularize the implementation of patterns, this is a useful thing to keep in mind.
  • Design patterns are a very clear demonstration of the value of domain-specific compositions; the loss of the design intentions, and the resulting tangling and scattering of design patterns in the implementation have bothered us for a long time. If we are able to express design pattern implementations modularly, reuse them, and especially make them explicit in the implementation, this can help to clarify our implementations. Form an architecure point of view, encoding tactical and strategic architectural decisions in explicit composiiton operators can be very attractive as well.
PS: note that an implementation of a pattern does never replace the actual pattern description! The design knowledge about the intent, applicability, consequences and forces that are captured in a pattern description can never be replaced by code!

 

 
Joomla Templates by Joomlashack