3. Variant Management

In these patterns, commonality of a set of related objects is factored out and described in one place. Different objects can then be treated uniformly in the same program.

Superclass

Purpose: provide uniform treatment of variant classes by placing common interface into superclass; variants are subclasses.

Flexibility: add new subclasses/variants.

Implementation: subclassing, inheritance, overriding.

Strategy

Purpose: dynamically exchange algorithm variants.

Flexibility: replace/add algorithms used.

Implementation: common interface/superclass for algorithm variants, multiple implementations of algorithms, delegation of implementation.

Composite

Purpose: handle parts-whole hierarchies; clients treat atomic objects and composites uniformly.

Flexibility: multiple atomic objects and composites.

Implementation: common interface for composites and atoms in superclass, multiple implementations.

Template Method

Purpose: specify algorithm skeleton using primitives; vary primitives in subclasses or by delegation.

Flexibility: multiple families of primitives.

Implementation: common interface for primitives across families as abstract functions, implementation in subclasses.

Factory Method

Purpose: specify creation skeleton using constructor primitives; vary primitives in subclasses.

Flexibility: multiple families of constructor primitives.

Implementation: common constructor interface across families as abstract functions, implementation in subclasses.

Builder

Purpose: Same as Factory Method, but use delegation instead of subclassing to choose construction primitives.

Abstract Factory

Purpose: bundle constructors for family of related objects into one object (the factory).

Flexibility: multiple families of constructors.

Implementation: common constructor interface across families, multiple implementations, factory invokes creation operations directly from chosen family.

Previous group Next group Back to the top