Meta-Patterns:

A New Approach

To Design Patterns.

 

 

Moisés Daniel Díaz Toledano.

Email : moises@moisesdaniel.com

WebSite : http://www.moisesdaniel.com/wri/metapatterns.html

 

1.0.- Design patterns.

The notion of 'design pattern' existed with a lot of anteriority to their common use in the computer community [7][6]. However it is commonly accepted that the work that originated this discipline (in the way that we today understand it) was the GOF book [8][3].

Exist numerous definitions of the term 'pattern'[1][2][8][9]. One of them was coined by Richard Gabriel [1] and say the following : "Each pattern is a three-part rule, which expresses a relation between a certain context, a certain system of forces which occurs repeatedly in that context, and a certain software configuration which allows these forces to resolve themselves". We can also accept the following one: "A pattern is the abstract representation of a good solution for a concrete, and generally frequent, problem that happens in one or more contexts".

In general, the patterns are structured in 'Patterns Languages ' [12], being able to define these as: "The specification of a series of roles (patterns) and their relationships (patterns) that allow us to describe good solutions to the different problems that appear in a specific context."

The principal objective of design patterns is capturing good practices that allow us to improve the quality of the design of systems, determining objects that support useful roles in a specific context, encapsulating complexity, and making it more flexible.

 

We can observe that the structure of these solutions (patterns) repeats, using a series of basic mechanisms (even in different levels of abstraction) to produce the same effects in the system. To know these common mechanisms allows us to have a clearer vision on patterns, as well as to have the capacity to generate them.

2.0.- Meta-Patterns.

We all want to build correct, robust, expandable and reusable software. We should be conscious that this group of external quality factors keeps a direct relationship with the internal quality of the same one, that is to say with its correction, flexibility, etc. However...

How do we get correction? One of the fundamental mechanisms to achieve it, consists on reducing the inherent complexity of the problem, encapsulating abstractions as well as normalizing and standardizing (uniforming).

How do we get flexibility? Basically adding indirection (decoupling abstractions).

2.1.- Objective-Mechanism Diagram.

We can visualize all this in a text diagram called Objective-mechanism Diagram and that it represents several levels of abstraction:

Diagram:

- Correct Software.

·         Divide the complexity (I simplify the problem).

o        Encapsulating: Functions, classes, components, aplicacions, systems (basically structural). How do we get the simplicity in....?

§         Functions: functional simplicity, same semantic level in their speech.

§         Code: Notation, validation mechanisms, initialization mechanisms, mechanisms for errors treatment, formatting the code [13].

- Flexible-Reusable Software.

·         Adding Indirection (decoupling).

o        We build an intermediate element (winning manipulation capacity , etc also goes away more than the problem in itself, and it constitutes another element to maintain). These intermediate elements can be a:

§         Function.

In a principle we can understand these Objective-mechanisms like patterns generators since they help us to create design patterns. For this reason I will denominate them Meta-patterns, passing to specify them inside the context of the object oriented design patterns (but thet are applicable to almost all abstraction levels).

2.2.- Meta-pattern Encapsulator.

- Problem: We have certain functionality or complex interaction distributed among several objects.

- Solution: To encapsulate this functionality or interaction in an object. The encapsulador provides simplification on the design generating a new role.

- Example problem: The creation of a complex structure of objects (Builder).

- Original Structure:

 

 

- Specific Solution :

 

- Abstract Representation: It’s a class.

- Some patterns that implement it: Builder, Facade, Iterator, Mediator, ...

 

 

 

 

 

 

 

 

 

2.3.- Meta-Pattern Adder.

- Problem: We have a class to which we want to add (or modify) certain functionality (in the wide sense of the word).

- Solution: We add another class in which we encapsulate this functionality. The Adder provides new functionality to the system through a new role that makes of mediator.

- Example Problem:

- Original Structure:

- Specific Solution:

 

 

 

 

- Abstract Representation:

With Polimorphism:

 

- Some patterns that implement it: Adapter (add a new interface), Proxy (add control on the access to an object), Command, Decorator...

 

 

 

 

 

 

 

 

2.4.- Meta-Pattern Decoupler.

- Problem: We have a complex functionality inside a class, and we want to add flexibility. - Solution: We can encapsulate this functionality in a aggregated (added) class to the original one. The Decoupler already provides flexibility to some functionality existent through a new role.

- Example Problem:

- Original Structure:

- Specific Solution:

 

- Abstract Representation:

 

 

 

 

 

 

With Polimorphism:

- Some patterns that implement it: Bridge (decoupling implementation), State (decoupling state of the object (behavior)), strategy (decoupling algorithm),...

These Meta-patterns or mechanisms, are present in the structure of almost all the design patterns.

In most of the design patterns we can see that they are one or even several Meta-patterns.

In the following section I present some design patterns generated in a very simple way using the meta-pattern concept.

 

 

3.0.- Some example patterns.

With the meta-pattern concept it is not only easier to understand the design patterns but generating them in our designs.

Here I describe some patterns direct consequence of the meta-pattern concept.

3.1.- Validator.

·         Problem: We have an object that has to make complex validations with the arguments that receives and on the objects with it is related.

3.2.- Persistor (persistence)

·         Problem: We have implemented inside a class their file persistence, and we need bigger flexibility (persistence in local databases, remote, etc).

3.3.- Set.

·         Problem: We have a great collection of objects (generally of the same type) and we have to enable a simple way to provide information about them.

3.4.- Logger.

·         Problem: We want to have a detailed registration of how the system works, with what we obtain a structure in which the role of maintaining a registration of the operation of the system is distributed among all objects.

 

 

 

 

 

 

 

 

 

 

 

 

 References:

·         [1] Pattern Definition Thread (http://c2.com/cgi/wiki?PatternDefinionThread , http://c2.com/cgi/wiki?MorePatternDefinionThread)