The Pattern Abstracts
from
Pattern-Oriented Software Architecture
A System of Patterns
F. Buschmann, R. Meunier, H. Rohnert, P.Sommerlad, M. Stal
John Wiley and Sons Ltd, Chichester, UK, 1996
Back to the
Book Page
The Architectural Patterns
The Layers pattern helps to structure applications that can be
decomposed into groups of subtasks in which each group of subtasks is
at a particularlevel of abstraction.
The Pipes and Filters pattern provides a structure for systems
that process a stream of data. Each processing step is encapsulated
in a filter component. Data is passed through pipes between adjacent
filters. Recombining filters allows you to build families of related
systems.
The Blackboard pattern is useful for problems for which no
deterministic solution strategies are known. In Blackboard several
specialized subsystems assemble their knowledge to build a possibly
partial or approximate solution.
The Broker pattern can be used to structure distributed
software systems with decoupled components that interact by remote
service invocations. A broker component is responsible for
coordinating communication, such as forwarding requests, as well as
for transmitting results and exceptions.
The Model-View-Controller pattern (MVC) divides an interactive
application into three components. The model contains the core
functionality and data. Views display information to the user.
Controllers handle user input. Views and controllers together comprise
the user interface. A change-propagation mechanism ensures consistency
between the user interface and the model.
The Presentation-Abstraction-Control pattern (PAC) defines a
structure for interactive software systems in the form of a hierarchy
of cooperating agents. Every agent is responsible for a specific
aspect of the application's functionality and consists of three
components: presentation, abstraction, and control. This subdivision
separates the human-computer interaction aspects of the agent from its
functional core and its communication with other agents.
The Microkernel pattern applies to software systems that must be
able to adapt to changing system requirements. It separates a minimal
functional core from extended functionality and customer-specific parts.
The microkernel also serves as a socket for plugging in these extensions
and coordinating their collaboration.
The Reflection 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.
The Design Patterns
The Whole-Part pattern helps with the aggregation of components
that together form a semantic unit. An aggregate component, the Whole,
encapsulates its constituent components, the Parts, organizes their
collaboration, and provides a common interface to its functionality.
Direct access to the Parts is not possible.
The Master-Slave pattern supports fault tolerance, parallel
computation and computational accuracy. A master component distributes
work to identical slave components and computes a final result from
the results these slaves return.
The Proxy pattern makes the clients of a component communicate
with a representative rather than to the component itself. Introducing
such a placeholder can serve many purposes, including enhanced
efficiency, easier access and protection from unauthorized access.
The Command Processor pattern separates the request for a service
from its execution. A command processor component manages requests as
separate objects, schedules their execution, and provides additional
services such as the storing of request objects for later undo.
The View Handler pattern helps to manage all views that a
software system provides. A view handler component allows clients
to open, manipulate and dispose of views. It also coordinates
dependencies between views and organizes their update.
The Forwarder-Receiver pattern provides transparent
inter-process communication for software systems with a peer-to-peer
interaction model. It introduces forwarders and receivers to decouple
peers from the underlying communication mechanisms.
The Client-Dispatcher-Server pattern introduces an intermediate
layer between clients and servers, the dispatcher component. It provides
location transparency by means of a name service, and hides the details
of the establishment of the communication connection between clients
and servers.
The Publisher-Subscriber pattern helps to keep the state of
cooperating components synchronized. To achieve this it enables
one-way propagation of changes: one publisher notifies any number of
subscribers about changes to its state.
The (C++) Idiom
The Counted Pointer idiom makes memory management of dynamically-
allocated shared objects in C++ easier. It introduces a reference
counter to a body class that is updated by handle objects. Clients
access body class objects only through handles via the overloaded
operator->().
Back to the
Book Page
|