Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, and Michael Stal
"The Reflection architectural pattern provides a mechanism for changing structure and behavior of software systems dynamically. It supports the modification of fundamental aspects, such as type structures and function call mechanisms. In this pattern, an application is split into two parts. A meta level provides information about selected system properties and makes the software self-aware. A base level includes the application logic. Its implementation builds on the meta level. Changes to information kept in the meta level affect subsequent base-level behavior." (Buschmann, F., R. Meunier, H. Rohnert, P. Sommerlad, and M. Stal. Pattern-Oriented Software Architecture: A System Of Patterns. West Sussex, England: John Wiley & Sons Ltd., 1996)
The idea of the Reflection pattern is to make the software self-aware, and make selected aspects of its structure and behavior accessible for adaptation and change. This leads to an architecture that is split into two major parts: a meta level and a base level. The meta level provides a self-representation of the software to give it knowledge of its own structure and behavior, and consists of so-called metaobjects. Metaobjects encapsulate and represent information about the software (i.e. type structures, algorithms, function call mechanisms). The base level defines the application logic. Its implementation uses the metaobjects to remain independent of those aspects that are likely to change. For example, base-level components may only communicate with each other via a metaobject that implements a specific user-defined function call mechanism. Changing this metaobject changes the way in which base-level components communicate, but without modifying the base-level code. An interface is specified for manipulating the metaobjects. It is called the metaobject protocol (MOP), and allows clients to specify particular changes. The metaobject protocol itself is responsible for checking the correctness of the change specification, and for performing the change. Every manipulation of metaobjects through the metaobject protocol affects subsequent base-level behavior. For a more detailed Motivation description for this pattern see: Buschmann, F., R. Meunier, H. Rohnert, P. Sommerlad, and M. Stal. Pattern-Oriented Software Architecture: A System Of Patterns. West Sussex, England: John Wiley & Sons Ltd., 1996.
This pattern has been used on the following systems: CLOS. Operations defined for objects are called generic functions, and their processing is referred to as generic function invocation. The process of generic function invocation executes a certain sequence of meta-level generic functions. Protocol users can vary the behavior of an application by modifying these generic functions or the generic functions of the metaobjects they call through the CLOS metaobject. (Keene, S.E., Object-Oriented Programming in Common Lisp - A Programmers Guide to CLOS, Addison-Wesley, 1989.) (Kiczales, G., J. des Rivieres, D. Bobrow. The Art of the Metaobject Protocol. MIT Press, 1991.) MIP. This is a run-time type information system for C++ that is mainly used for introspective access to the type system of an application. Every type of a C++ software system is represented by a set of metaobjects that provide general information about that type. The metaobject protocol of MIP allows you to specify and modify the metaobjects that provide run-time type information. It offers appropriate functions for every layer of the MIP functionality. (Buschmann, F., K. Kiefer, M. Stal, and F. Paulisch. The Meta-Information-Protocol: Run-Time Type Information for C++, Proceedings of IMSA 92, pp. 82-87.) PGen. This MIP-based persistence component for C++ allows an application to store and read arbitrary C++ object structures. (Tichy, W.F., J. Heilig, and F.N. Paulisch, A Generative and Generic Approach to Persistence, C++ Report, SIGS Publication, January 1994.) NEDIS. This car-dealer system uses the Reflection pattern to adapt to the specific requirements of a customer and a country. (Eisenhauer, R., S. Kumsta, F. Miralles, K. Mobius, U. Steinmuller, P. Stobbe, and C. Vester, Architektur-Handbuch fur Software-Architekten, Siemens Nixdorf Informationssysteme AG, internal report, 1994.) OLE 2.0 provides the ability to expose and access type information about OLE objects and their interfaces which may be used to access structural information about OLE objects and create invocations of OLE interfaces. (Brockschmidt, K., Inside OLE 2, Microsoft Press, 1994.)
Microkernel pattern
Microkernel pattern, Reflection pattern, Buschmann patterns, architectural patterns, Open Implementation pattern, Meta-Level Architecture pattern, adaptable systems, dynamic software system change
any system that needs to support its own modificationpersistence
extending behaviors of an existing hierarchy is impracticalfrequent change requests/requirements changeneed a mechanism to expose customizable elements of a system while hiding core elementsneed to modify object behaviors dynamically without affecting existing objectssystem evolves over time
changeability and extensibility of componentschanging a software system is easyenhanced maintainability and extensibility of the systemno explicit modification of source codesupport for many kinds of change
complexity of design and implementationincreased number of objectsmodifications at the meta level may cause damagerestricted efficiencysupporting new kinds of products is difficult
Simple implementation of the pattern - MetaobjectProtocol. MetaObjectProtocol.javaSimple implementation of the pattern - MetaLevel. MetaLevel.javaSimple implementation of the pattern - BaseLevel. BaseLevel.javaSimple implementation of the pattern. reflection.h