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.
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.
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 Broker pattern hides the implementation details of remote service invocation by encapsulating them into a layer other than the business component itself.
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.
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.
Memory Mangement Pattern
The Counted Pointer pattern supports memory management by counting references to dynamically created objects.
This pattern adds another level of inheritance to Visitor, providing a default implementation that takes advantage of the inheritance relationships in a polymorphic hierarchy of elements.
The Extension Interface design pattern allows multiple interfaces to be exported by a component, to prevent bloating of interfaces and breaking of client code when developers extend or modify the functionality of the component.
Attach additional methods to a class. Whereas Decorator requires that the core class's interface remain fixed as successive "wrappers" are applied, Extension Objects allow the class's interface to grow incrementally and dynamically.
Trade the performance overhead of a small number of run-time type tests for reduced complexity and coupling in the visitor and element classes by testing the feasibility of a visit operation before performing it.
The Forwarder-Receiver design 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 mechanism.
The Half-Sync/Half-Async architectural pattern decouples asynchronous and synchronous service processing in concurrent systems, to simplify programming without unduly reducing performance. The pattern introduces two intercommunicating layers, one for asynchronous and one for synchronous service processing.
The intercepting filter design pattern is used when we want to do some pre-processing / post-processing with request or response of the application. Filters are defined and applied on the request before passing the request to actual target application.
The Layered architectural pattern helps to structure applications that can be decomposed into groups of subtasks in which each group of subtasks Is at a particular level of abstraction.
The Leader/Followers architectural pattern that provides an efficient concurrency model where multiple threads take turns sharing a set of event sources in order to detect, demultiplex, dispatch, and process service requests that occur on the event sources.
The Manager design pattern encapsulates management of a class’ objects into a separate manager object. This allows variation of management functionality independent of the class and the manager’s reuse for different classes.