Behavioral Pattern
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.
Behavioral Pattern
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.
Structural Pattern
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.
Behavioral Pattern
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.
Behavioral Pattern
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.
Behavioral Pattern
Instead of using a null reference to convey absence of an object (for instance, a non-existent customer), one uses an object which implements the expected interface, but whose method body is empty. The advantage of this approach over a working default implementation is that a Null Object is very predictable and has no side effects: it does nothing.
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.
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.
Structural Pattern
Decouple instances from their classes so that those classes can be implemented as instances of a class. Type Object allows new "classes" to be created dynamically at runtime, lets a system provide its own type−checking rules, and can lead to simpler, smaller systems.