An abstract factory offers the interface for creating a set of related or dependant objects without explicitly specifying their classes. The type of the created objects are determined at run-time.
Event Handling Pattern
The Acceptor-Connector design pattern decouples the connection and initialization of cooperating peer services in a networked system from the processing performed by the peer services after they are connected and initialized.
The active object design pattern decouples method execution from method invocation for objects that each live in their own thread of control. The goal is to introduce concurrency, by using asynchronous method invocation and a scheduler for handling requests.
An object that encapsulates a row from a database table or view, by providing access to the database and adding domain logic. Because the data managing operations are implemented directly on the object, it is tightly coupled to the storage technology.
The Acyclic Visitor pattern allows new functions to be added to existing class hierarchies without affecting those hierarchies, and without creating the dependency cycles that are inherent to the GoF Visitor pattern.
The adapter pattern is a design pattern that is used to allow two incompatible types to communicate. Where one class relies upon a specific interface that is not implemented by another class, the adapter acts as a translator between the two types.
Event Handling Pattern
The Asynchronous Completion Token design pattern allows an application to demultiplex and process efficiently the responses of asynchronous operations it invokes on services.
The Blackboard pattern shows how a complex problem, such as image or speech recognition can be broken up into smaller, specialized subsystems that work together to solve a problem.
The bridge pattern is a design pattern that separates the abstract elements of a class from its technical implementation. This provides a cleaner implementation of real-world objects and allows the implementation details to be changed easily.
The Broker pattern hides the implementation details of remote service invocation by encapsulating them into a layer other than the business component itself.
The Broker Revisited pattern connects clients with remote objects by mediating invocations from clients to remote objects while encapsulating the details of network communication.
Instead of using numerous constructors, the builder pattern uses a builder object, that instantiates and initializes objects using a multiple of steps.
The chain of responsibility pattern is a design pattern that defines a linked list of handlers, each of which is able to process requests. When a request is submitted to the chain, it is passed to the first handler in the list that is able to process it.
A dispatcher component is an intermediary between clients and servers. The dispatcher provides location transparency with a name service and hides details of the communication connection.
A command object encapsulates a request as an object. This object is sent to a receiver which executes the command. The advantage of this technique is that the requests can be queued, logged or implemented to support undo/redo.
Command and Query Responsibility Segregation uses the same definition of Commands and Queries and maintains the viewpoint that they should be pure. The fundamental difference is that in CQRS objects are split into two objects, one containing the Commands one containing the Queries.
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 Component Configurator design pattern allows an application to link and unlink its component implementations at run-time without having to modify, recompile, or statically relink the application.
The composite pattern describes a way to create tree structures using objects and object groups. The clients can access and use individual objects and compositions in the same manner.
A Composition Root is a (preferably) unique location in an application where modules are composed together.