Annex B: Design Patterns

B1.Abstract Factory

Description

When various families of related objects have to be represented while masking their differences with the customers, this pattern proposes the definition of a centralised abstract interface of creation of a set of objects which can be specialised.

Structure and Components

Structure and Components of the Abstract Factory design pattern

• Factory defines the abstract interface for the creation of a family of objects,
• Factory1 and Factory2 carry out the creation of the objects by encapsulating the choice of the concrete classes,
• ProductA and ProductB define the interfaces of manipulation of the objects to be handled in a family,
• ProductA1 , ProductA2 , ProductB1 and ProductB2 define the concrete behaviours of the objects,
• FactoryClient creates the objects of a family and handles them through their abstract interface.

Collaborations

• a factory delegates to its subclasses the effective creation of the objects of a family,
• the client reaches the objects created only by their abstract interface,
• the objects of a same family can cooperate directly between them if necessary.

Strengths and Weaknesses

the maintenance of the coherence between objects is favoured,

the substitution of a concrete class by another is facilitated and remains transparent for the client,

if the direct co-operation between the concrete objects is necessary, these objects are made less reusable and interchangeable.

Use in CBR*Tools

Objects necessary to the reasoning (phase of reasoning, target case, objects backing up the state of the reasoning, etc.) represent a family whose coherence should be assured. This is why, an abstract factory ( ReasonerFactory class) is used to join together the operations of creation of these objects. This factory is specialised ( TimeExtendedReasonerFactory class) in order to declare the operations of creation of specific objects for the indexing by behavioural situations.

Brigitte Trousse
Last modified: Fri Sep 28 13:51:13 MEST 2001