Software Design and Architectural Patterns

Presentation-Abstraction-Control

Architectural Pattern

The PAC architectural pattern 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.

Proactor

Event Handling Pattern

The Proactor architecture pattern demultiplexes and dispatches service requests that are triggered by the completion of asynchronous operations.

Product Trader

Creational Pattern

Lets clients create objects by naming an abstract superclass and by providing a specification. A Product Trader decouples the client from the product and thereby eases the adaptation, configuration and evolution of class hierarchies, frameworks and applications.

Prototype

Creational Pattern

The prototype pattern is used to instantiate a new object by copying all of the properties of an existing object, creating an independent clone. This practise is particularly useful when the construction of a new object is inefficient.

Proxy

Structural Pattern

The proxy pattern is used to provide a surrogate or placeholder object, which references an underlying object. The proxy provides the same public interface as the underlying subject class, adding a level of indirection by accepting requests from a client object and passing these to the real subject object as necessary.

Publish/Subscribe (pub/sub)

Architectural Pattern

Publish/Subscribe is a messaging pattern where a publisher sends messages to a channel without the knowledge of who is going to receive them. It is the responsibility of the channel to deliver a copy of the messages to each subscriber.

Reactor

Event Handling Pattern

The Reactor design pattern handles service requests that are delivered concurrently to an application by one or more clients.

Reflection

Architectural Pattern

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.

Repository

Architectural Pattern

A Repository mediates between the domain and data mapping layers, acting like an in-memory domain object collection. Client objects construct query specifications declaratively and submit them to Repository for satisfaction. Objects can be added to and removed from the Repository, as they can from a simple collection of objects, and the mapping code encapsulated by the Repository will carry out the appropriate operations behind the scenes.

Scoped Locking

Synchronization Pattern

The Scoped Locking C++ idiom ensures that a lock is acquired when control enters a scope and released automatically when control leaves the scope, regardless of the return path from the scope.

Service Locator

Structural Pattern

The service locator pattern encapsulates the processes involved in obtaining a service with a strong abstraction layer. The pattern uses a central registry known as the "service locator", which on request returns the information necessary to perform a certain task. The pattern is often considered an anti-pattern, because it hides the dependencies of class (in contrast to constructor injection).

Single responsibility principle

Principle

A class should have one, and only one, reason to change.

Singleton

Creational Pattern

A singleton is an object whose class can only have one instance. A singleton class ensures that only one instance of the class can be created. The pattern is often called an anti-pattern because it may lead to high coupling of components.

Sponsor-Selector

Behavioral Pattern

The Sponsor-Selector pattern can be used to provide a mechanism for selecting the best resource for a task from a set of resources that changes dynamically. It allows a software system to integrate new resources, and new knowledge about resources, at run-time in a way that is transparent to users of the resources. This pattern is based on the idea of separating three kinds of responsibilities: knowing when a resource is useful, selecting among resources, and using a resource.

State

Behavioral Pattern

The state pattern is used to alter the behaviour of an object as its internal state changes. The pattern allows the class for an object to apparently change at run-time.

Strategized Locking

Synchronization Pattern

The Strategized Locking design pattern parameterizes synchronization mechanisms that protect a component's critical sections from concurrent access.

Strategy

Behavioral Pattern

The strategy pattern is used to create an interchangeable family of algorithms from which the required process is chosen at run-time.

Template Method

Behavioral Pattern

The template method pattern is used to define the basic steps of an algorithm and allow the implementation of the individual steps to be changed.

Thread-Safe Interface

Synchronization Pattern

The Thread-Safe Interface design pattern minimizes locking overhead and ensures that intra-component method calls do not incur `self-deadlock' by trying to reacquire a lock that is held by the component already.

Thread-Specific Storage

Concurrency Pattern

The Thread-Specific Storage design pattern allows multiple threads to use one `logically global' access point to retrieve an object that is local to a thread, without incurring locking overhead on each object access.