Meta Pattern

Problem: You have a certain representation of a system, i.e. a model. You want to describe this representation, i.e. build a meta-model.

Force: There is some (mental, technical) overhead associated with this description. You want to keep that overhead to a minimum.

Solution: Use the same representation to describe the model and the meta-model.

Examples:

The use of tables to represent information about tables (data dictionary) in database systems.

The use of classes/objects to represent information about classes/objects (e.g. the "Class" class in Java).

The use of patterns to represent information about patterns (see Pattern Pattern; Pattern Language Pattern (?), afaik, remains yet to be written).

Another force this resolves is the desire or need to do the same kind of processing on the metadata that you wish to do on the data. For example, you may want to manage or maintain it using the same set of tools. (The need to reuse is probably part of the "overhead" mentioned above.)

Example: The schema information in a relational database...

Is queryable using standard SQL.

Has its storage managed in the same way as ordinary tables.

I admit this pattern, if it is one, may not be very useful. I like it anyway, probably because of its Fractal Nature. --Falk Bruegmann

See also Alternate Hard And Soft Layers for more ideas about fractal complexity available through representing the meta-model in the same language as used to represent the model. -- David Cymbala

Patterns describe a relation between a problem, a solution and a context. A metapattern is a more generelized form of pattern in such a way that it does not apply to a specific context anymore. One could say that a metapattern is a context free pattern. -- Hugo Heitmeijer

See also Myth Of Metadata for common misconceptions with meta data (not with the Meta Pattern). -- Thomas Weidenfeller

Other examples: Shield Pattern