Composite Design Pattern in TypeScript (Part 1): Motivation, Applicability & Structure
In this series of articles, I hope to further clarify the specific ideas discussed in the book “Design Patterns: Elements of Reusable Object-Oriented Software” about composite design pattern. I attempted to illustrate the tricky sections using TypeScript examples.
Intent
Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.
Motivation
Graphics applications like drawing editors and schematic capture systems (Schematic capture systems, also known as schematic entry systems or schematic design tools, are software applications used primarily in electronic design automation (EDA) for creating and editing electronic circuit diagrams.) let users build complex diagrams out of simple components. The user can group components to form larger components, which in turn can be grouped to form still larger components. A simple implementation could define classes for graphical primitives such as Text and Lines plus other classes that act as containers for these primitives.
But there’s a problem with this approach: Code that uses these classes must treat primitive and container objects differently, even if most of the time the user treats them identically. Having to distinguish these objects makes the application more complex. The Composite pattern describes how to use recursive composition so that clients don’t have to make this distinction.
// Abstract class Graphic
abstract class Graphic {
abstract Draw(): void;
Add(graphic: Graphic): void {
throw new Error("Unsupported operation");
}
Remove(graphic: Graphic): void {
throw new Error("Unsupported operation");
}
GetChild(index: number): Graphic {
throw new Error("Unsupported operation");
}
}
// Primitive graphical objects
class Line extends Graphic {
Draw(): void {
console.log("Drawing a Line");
}
}
class Rectangle extends Graphic {
Draw(): void {
console.log("Drawing a Rectangle");
}
}
class Text extends Graphic {
Draw(): void {
console.log("Drawing Text");
}
}
// Composite class
class Picture extends Graphic {
private graphics: Graphic[] = [];
Draw(): void {
for (const graphic of this.graphics) {
graphic.Draw();
}
}
Add(graphic: Graphic): void {
this.graphics.push(graphic);
}
Remove(graphic: Graphic): void {
const index = this.graphics.indexOf(graphic);
if (index !== -1) {
this.graphics.splice(index, 1);
}
}
GetChild(index: number): Graphic {
return this.graphics[index];
}
}
// Usage example
const line = new Line();
const rectangle = new Rectangle();
const text = new Text();
const picture = new Picture();
picture.Add(line);
picture.Add(rectangle);
picture.Add(text);
const bigPicture = new Picture();
bigPicture.Add(picture);
bigPicture.Draw();The key to the Composite pattern is an abstract class that represents both primitives and their containers. For the graphics system, this class is Graphic. Graphic declares operations like draw that are specific to graphical objects. It also declares operations that all composite objects share, such as operations for accessing and managing its children.
The subclasses Line, Rectangle, and Text define primitive graphical objects. These classes implement draw to draw lines, rectangles, and text, respectively. Since primitive graphics have no child graphics, none of these subclasses implements child-related operations.
The Picture class defines an aggregate of Graphic objects. Picture implements draw to call Draw on its children, and it implements child-related operations accordingly. Because the Picture interface conforms to the Graphic interface, Picture objects can compose other Pictures recursively with other Picture objects (or maybe primitive objects).
The following diagram shows a typical composite object structure of recursively composed Graphic objects:
Applicability
Use the Composite pattern when
· you want to represent part-whole hierarchies* of objects.
* Part-whole hierarchies are organizational structures that describe the relationship between a whole object and its constituent parts. Whole is the complete system or entity that is made up of interconnected parts and Parts are the individual components that combine to form the whole. Each part can itself be a whole at a lower level of the hierarchy if it consists of smaller parts.
· you want clients to be able to ignore the difference between compositions of objects and individual objects. Clients will treat all objects in the composite structure uniformly.
Structure
A typical Composite object structure might look like this:
Participants
• Component (Graphic)
- declares the interface for objects in the composition.
- implements default behavior for the interface common to all classes, if reasonable.
- declares an interface for accessing and managing its child components.
- (optional) defines an interface for accessing a component’s parent in the
recursive structure, and implements it if that’s appropriate and is needed.
• Leaf (Rectangle, Line, Text, etc.)
- represents leaf objects in the composition. A leaf has no children.
- defines behavior for primitive objects in the composition.
• Composite (Picture)
- defines behavior for components having children.
- stores child components.
- implements child-related operations in the Component interface.
• Client
-manipulates objects in the composition through the Component interface.
Collaborations
Clients use the Component class interface to interact with objects in the composite structure. If the recipient is a Leaf, then the request is handled directly. If the recipient is a Composite, then it usually forwards requests to its child components, possibly performing additional operations before and/or after forwarding.
In the next Part we will talk about implementation and related patterns of composite design pattern.
