Summary MetaPatterns can be contemplated like a form of understanding the underlying mechanisms of patterns and the form in which they work, and even as a new classification of patterns patterns. The principal objective of 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.

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.

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).

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

Diagram:

• Divide the complexity (I simplify the problem).
  • Encapsulating: Functions, classes, components, aplicacions, systems (basically structural). How do we get the simplicity in....?
    • Functions: functional simplicity, same semantic level in their speech.
    • Classes: identificative unicity, avoiding semantic difference (methods that treat similar abstractions, relationships of similar abstract level...).
    • ......
  • Standardization - Normalization (basically is functional).
    • Code: Notation, validation mechanisms, initialization mechanisms, mechanisms for errors treatment, formatting the code [13].
    • Levels of uniform abstraction in the speeches (programming).
    • Interaction Mechanisms (also visualization). ).
    • Communication Mechanisms among entities of similar levels of abstraction. I use the same ones 'methods' to make the same things (components, etc). ).

• Adding Indirection (decoupling).
  • 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.
    • Class.
    • Classes + Polymorphism.
    • Component.
    • Subsystem.
    • Etc...

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 that are applicable to almost all abstraction levels).

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

- Solution: To encapsulate this functionality or interaction in an object. The encapsulator 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, ...

- 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 Polymorphism:

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

- 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.

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.

• Problem: We have an object that has to make complex validations with the arguments that receives and on the objects with it is related.
• Solution: Decoupling this functionality in another class (Validator) to make simpler, explandable, etc the original class.
• It structures: Meta-pattern Decoupler in which we encapsulate the validations that it should make the object. If we need more flexibility we could evolve toward a polimorphic structure (decoupler-polimorphic).

• Problem: We have implemented inside a class their file persistence, and we need bigger flexibility (persistence in local databases, remote, etc).
• Solution: Decoupling the persistence mechanisms of this class in another class (Persistor).
• It structures: Meta-pattern Decoupler (polimorphic). We encapsulate in it the persistence mechanisms.

• 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.
• Solution: We give origin to a new Role: Set-Mapper. These believe a structure for referencing the set. We have now an only access point to the same ones and it centralizes the information of the group of these objects.
• It structures: Meta-pattern Adder.

• 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.
• Solution: We encapsulate all the functionality of registering information in a class: the Logger.
• It structures: Meta-pattern Encapsulator.

• [1] Pattern Definition Thread (http://c2.com/cgi/wiki?PatternDefinionThread , http://c2.com/cgi/wiki?MorePatternDefinionThread)
• [2] A Pattern Definition, Software Patterns by James O. Coplien Bell Laboratories Naperville, Illinois (http://hillside.net/patterns/definition.html)
• [3] GOF (en la red) (http://hillside.net/patterns/books//DPBook/DPBook.html)
• [4] A Patterns BookList on the WikiWiki Web: http://c2.com/cgi/wiki?BookList
• [5] The Patterns Home Page http://hillside.net/patterns/patterns.html
• [6] Patter Origins and History http://www.enteract.com/~bradapp/docs/patterns-nutshell.html#Pattern_History
• [7] A Pattern Language: Towns, Buildings, Construction (APL) Christopher Alexander; Oxford University Press, 1977
• [8] Design Patterns: Elements of Reusable Object-Oriented Software (GoF) Gamma, Helm, Johnson, Vlissides; Addison-Wesley, 1994
• [9] Pattern-Oriented Software Architecture: A System of Patterns (POSA) Buschmann, Meunier, Rohnert, Sommerlad, Stal; Wiley and Sons, 1996
• [10] Pattern Languages of Program Design (PLoPD1) Coplien and Schmidt (editors); Addison-Wesley, 1995
• [11] Plop conferences documents, http://jerry.cs.uiuc.edu/~plop
• [12] Patterns Mailing Lists, http://www.hillside.net/patterns/Lists.html
• [13] Good Programming Techniques, Moises Daniel, http://www.geocities.com/moisesdaniel01/Articles/GoodProgTech.htm

For a Full Graphical version visit:

http://www.geocities.com/moisesdaniel01/Articles/MetaPatternsEnglish/MetaPatternsEnglish.htm