The composite design pattern allows us to create composite objects from different components
. The components that make up the composite object must either implement a common interface or extend an abstract class for the composite object. The common methods on composite objects include, add, remove, display, and find. Let’s explain this using a real world example
. We will use an information system for managing student records. Students can do all or part of the following activities in a typical college / university.
The above activities give us a structured hierarchy of students’ activities that are different in nature
- New students fill in application forms
- Students enroll for semester courses
- Students subscribe for services such as internet usage, library etc.
- Students register for exams
- Students occasionally break school property
. Assume you have being asked to develop an integrated information management system that records the above student activities and includes a payments module.
The problem to be solved
Assume according to the system requirements given to you, students are expected to pay for the above activities. The billing is dependable on the services that the student has subscribed to
. Returning students do not need buy registration forms, students who do not break anything do not need to pay for damages. What about students who postpone studies, do we charge them exam fees? How can we come up with a single composite object with billable items? As you can see, producing a bill dependant on the activities is complex because the activities are all unique in their own ways.
How does the composite design pattern come to the rescue?From an accounting point of view, we really do not care about the nature of the object, whether all activities apply or the order in which they occur. All that matters is a student subscribed to a service
. The service has a billing code and if the student subscribed to it then that’s all we need to produce the student bill. A composite pattern solves this problem by defining a common interface with properties and methods that the class representing the activities can implement or extend if it is a class
. The interface will allow us to treat the activities in a uniform way regardless of their nature.
Major components of a composite design pattern
The composite pattern has three major components namely;
- IComponent: the interface that all the components implement. This can also be a class
- Component: the unique objects in their own ways that implement or extend the IComponent.
- Composite: the single object made up of many components.
The class diagram below shows how the components relate to one another
The table below shows the composite design pattern components as they relate to our problem
|Component||Real world object|
|IComponent||Student Activity abstract class/interface|
|Component||Student activity i.e. exam registration|
|Composite||Student Bill class|
Composite design pattern world real example class diagram
The class diagram below illustrates the physical implementation of the above student activities example
The above example has being implemented using simple console applications in Java and C-Sharp. The example for PHP uses a basic HTML page to output the results. The following images show the output from the programs.
When should you apply the composite design pattern
- When you want to treat to treat different objects uniformly regardless of their differences
- When you want to represent you part-whole hierarchies of structured objects
Step by step implementations of the above outputThe best way to learn something is by doing it yourself
. The following links have the source code for the trio implementation of the composite design pattern. The source code does not contain any code explanations just the steps and files you must create to run the programs successfully. You can use the comments section to ask questions if you would like some clarifications on the source code. As always, positive criticism is welcome.