Composite Design Pattern
Object & Reference Composition
Composite design patterns fall into one of the structural design patterns. Before diving into the composite design pattern, let me clarify a few points here. We can define composite objects as objects that contain other objects. For example, the company has divisions, and each division contains departments that contain teams, and so on.
Software engineers need the composite pattern since we would like to treat or manipulate the composite objects in the same way we manipulate the primitive objects. For example, let us assume the department as a primitive object that can be increased and decreased in the number of employees in it. And we would like to do the same pattern operation on division which is a composite object, containing other departments. The main point is we want to do operations on both primitives and composites in exactly the same way. If we want to distinguish between those two objects, thinking there are two different objects, our code will be too complex, leading to maintenance problems later on.
In the following cases, the composite design pattern is used:
Composite design pattern allows you to have a tree structure and ask each node to perform a task.
Pattern creates a tree structure of a group of objects.
Composite pattern is used where we need to treat a group of objects in a similar way as a single object. The composite pattern composes the objects in terms of the tree structure to represent a part-whole hierarchy.
In regards to a tree structure, the composite pattern treats each node in two ways, composite or leaf. Composite means it can have other objects below it. The leaf means it has no objects below it.
I have created a sample demo for composite patterns in my github here.
Thanks for reading!