ModelMaker Design Patterns - Delphi design pattern

Supported Patterns

  • Wrapper pattern (also called 'Adapter'), converts the interface of a class into another interface clients expect.
  • Mediator pattern , creates event handlers for a 'used' class and wires them. (Pascal only)
  • Singleton pattern , ensures a class only has one instance, and provides a global point of access to it.
  • Decorator pattern , attaches additional responsibilities to an object dynamically.
  • Lock pattern , provides a mechanism to temporarily lock some aspect of a class.
  • Reference counting pattern , provides a mechanism to control the life-span of an object with reference counting. (Pascal only)
  • Visitor pattern , represents an operation to be performed on the elements of an object structure by a class.
  • Observer pattern , defines a one-to-many dependency between objects so that when one object changes state, all its dependents are notified. (Pascal only)

Create your own patterns

  • User Definable Templates, let you create your own patterns from a set of selected class members.

When developing ModelMaker we were inspired a lot by the book 'Design Patterns, Elements of Reusable Object-Oriented Software' by Erich Gamma e.a. We decided to make design patterns an integral part of ModelMaker's modelling engine. Thus enabling us to support design patterns in a brand new way: as active agents looking over your shoulder while you are editing your model and automatically reflecting changes where ever needed, keeping the pattern's implementation up to date.

What is a Design Pattern?

In generic, according to Christopher Alexander: "Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice".

In software engineering, a design pattern is a proven solution for a general design problem. It consists of communicating classes and objects that are customised to solve the problem in a particular context. The usefulness of the solution a pattern presents has been proven in many designs. As such it captures design experience of experienced programmers. A designer who is familiar with such patterns can apply them immediately to design problems without having to rediscover them.

This way design patterns make it easier to reuse successful designs and architectures. Expressing proven techniques as design patterns makes them more accessible to developers of new systems. Design patterns help you choose design alternatives that make a system reusable and avoid alternatives that compromise reusability. Design patterns can even improve the documentation and maintenance of existing systems by furnishing an explicit specification of class and objects interactions and their underlying 'intend';. Put simply, design patterns help a designer get a design 'right' faster.

These design patterns as used in ModelMaker are not about designs such as linked lists and hash tables that can be encoded in classes and reused as is. Nor are they complex, domain specific designs for an entire application or subsystem.

Patterns in ModelMaker

In ModelMaker patterns are part of the modelling engine, just like classes and members. Before you apply a specific pattern, you have to provide it's context, such as selecting the class(es) and / or member(s) on which to operate. When a pattern is applied, it will insert (user adjustable) code into the model. This usually consists of classes, members or code sections in methods. The total of all inserted parts makes up the complete implementation of the pattern. So far the pattern is like a wizard that is able to reason about what to insert where.

The power of ModelMaker is that patterns optionally stay alive after inserting the pattern related code. Because the pattern is alive, it can reflect changes in the model to the pattern related code or even automatically add or delete members if needed.

It is important to notice that you won't see a pattern somewhere in the source code. The pattern is represented there only by means of the classes, members and code sections it inserted. A pattern can be applied multiple times in a model or even on the same class. Patterns might even interact with or extend each other.

Creating your Own Patterns

Although they are not active patterns, the "Parametric Code Templates" can be used to implement your own patterns. Detailed examples are available in the user manual

Additionally you may use the ModelMaker ToolsAPI to create your own pattern-like wizards. Using the MMToolsAPI is explained in the user manual. [link: This site] contains a good example to get you started with the MMToolsAPI.

Supported patterns

When deciding which of the patterns as described in "Design Patterns" by Gamma to support, we found that many patterns could be expressed using the same class and instance relations. For example the structure of a Proxy pattern is the same as a that for a Decorator pattern. Also many patterns can be implemented very easy using ModelMaker's ability to override methods and keep overridden methods restricted to their origins. Some patterns were hard to implement the ModelMaker way and little would be gained in doing so. Other patterns are so class library restricted that it didn't feel right to implement them in a generic tool. This reduced the number of patterns to the supported patterns listed above.

As we keep in touch with the pattern community, new patterns will be supported in time. We're also open to suggestions from users, so if you come up with new ideas about (generic) patterns to implement, please inform us.