Robert C. Martin

Author

Get more Information

Books

Patterns

Acyclic Visitor

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.

Default Visitor

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.

Extension Object

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.

Extrinsic Visitor

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.

Manager

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.

Null Object

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.

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.

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.

Type Object

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.