Composite Design Pattern in TypeScript (Part 2): Implementation, & Related Patterns
In Part 1 we discussed about motivation, applicability & structure of composite design pattern. Now lets take a look at its implementation and related patterns.
Implementation
There are many issues to consider when implementing the Composite pattern:
1.Explicit parent references. Maintaining references from child components to their parent can simplify the traversal and management of a composite structure. The parent reference simplifies moving up the structure and deleting a component. Parent references also help support the Chain of Responsibility pattern.
The usual place to define the parent reference is in the Component class. Leaf and Composite classes can inherit the reference and the operations that manage it.
With parent references, it’s important to ensure that each child component always correctly references its parent composite. This means that if a composite object contains children, those children should always recognize the composite as their parent. The easiest way to ensure this, is to change a component’s parent only when it’s being added or removed from a composite. If this can be implemented once in the Add and Remove operations of the Composite class, then it can be inherited by all the subclasses. Example:
abstract class Component {
parent: Composite | null = null;
setParent(parent: Composite | null) {
this.parent = parent;
}
getParent(): Composite | null {
return this.parent;
}
abstract operation(): void;
}
class Leaf extends Component {
operation(): void {
console.log("Leaf operation");
}
}
class Composite extends Component {
private children: Component[] = [];
add(child: Component): void {
child.setParent(this);
this.children.push(child);
}
remove(child: Component): void {
const index = this.children.indexOf(child);
if (index !== -1) {
child.setParent(null);
this.children.splice(index, 1);
}
}
operation(): void {
console.log("Composite operation");
for (const child of this.children) {
child.operation();
}
}
}
// Usage
const composite = new Composite();
const leaf1 = new Leaf();
const leaf2 = new Leaf();
composite.add(leaf1);
composite.add(leaf2);
console.log(leaf1.getParent() === composite); // true
console.log(leaf2.getParent() === composite); // true
composite.remove(leaf1);
console.log(leaf1.getParent() === null); // true2. Sharing components. It’s often useful to share components, for example, to reduce storage requirements. But when a component can have no more than one parent, sharing components becomes difficult. A possible solution is for children to store multiple parents. But that can lead to ambiguities as a request propagates up the structure. (The potential solution is Flyweight pattern)
3. Maximizing the Component interface. One of the goals of the Composite pattern is to make clients unaware of the specific Leaf or Composite classes they’re using. To attain this goal, the Component class should define as many common operations for Composite and Leaf classes as possible. The Component class usually provides default implementations for these operations, and Leaf and Composite subclasses will override them.
However, this goal will sometimes conflict with the principle of class hierarchy design that says a class should only define operations that are meaningful to its subclasses. There are many operations that Component supports that don’t seem to make sense for Leaf classes. How can Component provide a default implementation for them?
Sometimes a little creativity shows how an operation that would appear to make sense only for Composites can be implemented for all Components by moving it to the Component class. For example, the interface for accessing children is a fundamental part of a Composite class but not necessarily Leaf classes. But if we view a Leaf as a Component that never has children, then we can define a default operation for child access in the Component class that never returns any children. Leaf classes can use the default implementation, but Composite classes will reimplement it to return their children.
abstract class Component {
// Default implementation for adding a child does nothing
add(component: Component): void {
// Default implementation does nothing
}
// Default implementation for removing a child does nothing
remove(component: Component): void {
// Default implementation does nothing
}
// Default implementation for getting a child returns null
getChild(index: number): Component | null {
return null; // Leaf nodes have no children
}
// Abstract operation method to be implemented by subclasses
abstract operation(): void;
}4. Declaring the child management operations. Although the Composite class implements the Add and Remove operations for managing children, an important issue in the Composite pattern is which classes declare these operations in the Composite class hierarchy. Should we declare these operations in the Component and make them meaningful for Leaf classes, or should we declare and define them only in Composite and its subclasses?
The decision involves a trade-off between safety and transparency:
· Defining the child management interface at the root of the class hierarchy gives you transparency, because you can treat all components uniformly. It costs you safety because clients may try to do meaningless things like add and remove objects from leaves.
· Defining child management in the Composite class gives you safety, because any attempt to add or remove objects from leaves will be caught at compile-time. But you lose transparency, because leaves and composites have different interfaces.
We have emphasized transparency over safety in this pattern. If you opt for safety, then at times you may lose type information (for example, if you have a Component reference and you need to manage its children, you can’t directly call add or remove because the Component type doesn’t have these methods.) and have to convert a component into a composite. How can you do this without doing to a type-unsafe cast?
One approach is to declare an operation getComposite() in the Component class. Component provides a default operation that returns a null pointer. The Composite class redefines this operation to return itself through the this pointer:
class Component {
// Method to check if the component is a composite
getComposite(): Composite | null {
return null;
}
}
class Composite extends Component {
private children: Component[] = [];
// Method to add a child component
add(component: Component): void {
this.children.push(component);
}
// Method to get the composite itself
getComposite(): Composite {
return this;
}
}
class Leaf extends Component {
// Leaf-specific implementation
}getComposite method lets you query a component to see if it’s a composite. You can perform add and remove safely on the composite it returns.
// Example usage
const aComposite = new Composite();
const aLeaf = new Leaf();
let aComponent: Component;
let test: Composite | null;
aComponent = aComposite;
if (test = aComponent.getComposite()) {
test.add(new Leaf());
}
aComponent = aLeaf;
if (test = aComponent.getComposite()) {
test.add(new Leaf()); // Will not add leaf since getComposite() returns null
}Another way to check if an object is composite in TypeScript is using instanceof operation:
// Type-safe way using TypeScript's `instanceof` to avoid type-unsafe casts
if (aComponent instanceof Composite) {
aComponent.add(new Leaf());
}Of course, the problem here is that we don’t treat all components uniformly. We have to testing for different types before taking the appropriate action.
The only way to provide transparency is to define default add and remove operations in Component. That creates a new problem: There’s no way to implement Component.add without introducing the possibility of it failing. You can implement this method in 3 ways in Component:
· Do Nothing: One way to implement add in Component is to make it do nothing. However, this approach is problematic because if you try to add a child to a leaf node, it silently fails, which can lead to bugs.
· Produce Garbage: If you try to add a child to a leaf node and the add method does nothing, the child component is essentially ignored, which might lead to unused or “garbage” objects in your system.
· Delete Argument: Another approach is to make the add method in Component delete the child component if it’s called on a leaf. This ensures no garbage is produced, but it’s unexpected behavior and can lead to further issues, such as losing important data.
Usually, it’s better to make add and remove fail by default (perhaps by raising an exception) if the component isn’t allowed to have children or if the argument of remove isn’t a child of the component, respectively.
class Component {
add(component: Component): void {
throw new Error('This component cannot have children.');
}
remove(component: Component): void {
throw new Error('This component cannot have children.');
}
}
class Composite extends Component {
private children: Component[] = [];
add(component: Component): void {
this.children.push(component);
}
remove(component: Component): void {
const index = this.children.indexOf(component);
if (index === -1) {
throw new Error('The component to be removed is not a child of this component.');
}
this.children.splice(index, 1);
}
}
class Leaf extends Component {
// Leaf uses the default implementations of add and remove from Component, which will throw errors
}
// Example usage:
const leaf = new Leaf();
const composite = new Composite();
try {
leaf.add(new Leaf()); // Throws an error: "This component cannot have children."
} catch (error) {
console.error(error.message);
}
try {
leaf.remove(new Leaf()); // Throws an error: "This component cannot have children."
} catch (error: any) {
console.error(error.message);
}
const childLeaf = new Leaf();
composite.add(childLeaf); // Successfully adds childLeaf to composite
try {
composite.remove(new Leaf()); // Throws an error: "The component to be removed is not a child of this component."
} catch (error: any) {
console.error(error.message);
}
try {
composite.remove(childLeaf); // Successfully removes childLeaf from composite
console.log('Child leaf removed successfully.');
} catch (error: any) {
console.error(error.message);
}Another alternative is to change the meaning of “remove” slightly. If the component maintains a parent reference, then we could redefine Component.remove to remove itself from its parent. However, there still isn’t a meaningful interpretation for a corresponding add.
class Component {
private parent: Composite | null = null;
setParent(parent: Composite | null): void {
this.parent = parent;
}
getParent(): Composite | null {
return this.parent;
}
add(component: Component): void {
throw new Error('This component cannot have children.');
}
remove(): void {
if (this.parent) {
this.parent.removeChild(this);
} else {
throw new Error('This component does not have a parent.');
}
}
}5. Should Component implement a list of Components? You might be tempted to define a variable in Component to store list of children as an instance variable where the child access and management operations are declared. But putting the child pointer in the base class brings a space penalty for every leaf, even though a leaf never has children. This is worthwhile only if there are relatively few children in the structure.
6. Child ordering. Many designs specify an ordering on the children of Composite.
When child ordering is an issue, you must design child access and management interfaces carefully to manage the sequence of children. The Iterator pattern can guide you in this.
7. Caching to improve performance. If you need to traverse or search compositions frequently, the Composite class can cache traversal or search information about its children. The Composite can cache actual results or just information that lets it short-circuit the traversal or search. For example, the Picture class from the first example could cache the bounding box of its children. During drawing or selection, this cached bounding box lets the Picture avoid drawing or searching when its children aren’t visible in the current window.
Changes to a component will require invalidating the caches of its parents. This works best when components know their parents. So, if you’re using caching, you need to define an interface for telling composites that their caches are invalid.
8. Who should delete components? It’s usually best to make a Composite responsible for deleting its children when it’s destroyed. An exception to this rule is when Leaf objects are immutable and thus can be shared.
9. What’s the best data structure for storing components? Composites may use a variety of data structures to store their children. The choice of data structure depends (as always) on efficiency. In fact, it isn’t even necessary to use a general-purpose data structure at all. Sometimes composites have a variable for each child, although this requires each subclass of Composite to implement its own management interface. See Interpreter for an example.
Related Patterns
Often the component-parent link is used for a Chain of Responsibility.
Decorator is often used with Composite. When decorators and composites are used together, they will usually have a common parent class. So, decorators will have to support the Component interface with operations like add, remove, and getChild.
Flyweight lets you share components, but they can no longer refer to their parents.
Iterator can be used to traverse composites.
Visitor localizes operations and behavior that would otherwise be distributed across Composite and Leaf classes.
