These four papers are substantial works which have been presented at KoalaPlop (Asian Pacific Conference on Pattern Languages of Programs) in both 2000 and 2001. My shepherds (paper peer reviewers) were:
- Jim Coplien (MGM pattern)
- Ali Arsanjani (TI pattern)
- James Noble (RM pattern).
These final versions also incorporate comments and reviews from the attendees of KoalaPlop 2000 and 2001.
A central mediating class which records all the one-to-one, one-to-many and many-to-many
relationships between a group of selected classes.
Classes that use a Relationship Manager to implement their relationship properties and
methods have a consistent metaphor and trivial implementation code (one line calls).
In contrast - traditional "pointer" and "arraylist" techniques of implementing relationships are fully flexible but often require
a reasonable amount of non-trivial code which can be tricky to get working correctly and are
almost always a pain to maintain due to the detailed coding and coupling between classes
involved.
The MGM pattern is a variation of MVC (model view controller) or MVP (Model View Presenter) but takes into account the use of modern off the shelf GUI controls.
A MGM object displays a portion of a software application's data to the user, and optionally allows
that data to be altered by the user of the application. MGM is specifically suited to the display of
application data in contemporary, off-the-shelf GUI control widgets within a modern RAD (Rapid
Application Development) IDE. The MGM design pattern empowers a programmer to simulate
object-aware controls using off-the-shelf GUI controls.
The Transformation Interface is both a design pattern and an architectural pattern. It describes an
interface or layer, which offers services to transform an object into another format and back
again. A pair of methods on some class e.g. load/save are often the signature of a
Transformation Interface.
As design patterns become more mainstream, various IDE's (Integrated Development Environments) and UML modelling software environments have begun to introduce support for design patterns. For example, developers browse through a catalog of design patterns and drop one onto a UML workspace, whereupon various classes appear with the appropriate methods and attributes inserted. Usually there is an interface whereby roles in the design pattern can be mapped onto existing classes, or alternatively, new classes are created for you.
This paper explores the state of pattern automation software, discusses the pros and cons of various approaches and then goes on to discusses the broader issues raised by the attempt to automate something which some argue, in principle, perhaps should not be automated at all..