Design Patterns: Elements of Reusable Object-Oriented Software is the first and probably the most famous book about the Design pattern. It was first published in 1995, but thankfully those design patterns are still valid nowadays, the only outdated thing in this book may be the Smalltalk programming language, used in some examples. Anyway this book is still very good and popular: in fact I have decided to read this book when, in a job listing, it was expressly requested the knowledge of design patterns and of this book!
I will write a series of 15 articles about this book, making the summary of a couple chapters of this book in each one (the book is pretty big, it has over 500 pages). To deepen your knowledge of the argument, you can always buy the book @ Amazon.
The composite pattern
Like the name hints, this is a pattern designed to compose simple or already composed objects (without distinction between those two categories, by the adoption of a common interface) inside a tree structure.
There will not be differences between branches and leave regarding usage, the client will treat them uniformly: this is a really important fact, because it means the client will be simpler compared to a design with many have different objects with different interfaces and methods.
It is very useful in situations when we do not know in advance the level of complexity of the structure (through recursive composition we do not have to worry about the number of levels of composition).
The image from the GoF book was really complex, I think that the image you will find below, taken from a PDF called GoF Design Patterns – with examples using Java and UML2 released under a Creatuve cinnibs Attribution-ShareAlike 3.0 license, it’s more clear and easy to understand.
In the book there are several reccomandations about the implementation of the Composite Pattern:
- Make the Component interface as general and wide as possible. There are some border-line situations, like the methods to handle children: should they be declared in the Component interface, giving them some meaning also for the leaf, or should they be implemented directly into the Composite class? This is a trade-off, the first option favors transparency over safety
- Always mantain a parent reference: that is gonna make possible to traversate and manage the structure. Usually such reference is defined in the Component abstract class or interface. On the other hand, it is not always advisable to keep the opposite reference: store a list of any children for each node could be a tempting idea, but this list will be a waste of memory for all the leaf, since they will not have any children. If you have a very big structure, this waste of memory can be considerable and you have to think about if whether is it convenient to add such list or not.
- Make a composite object responsible for deleting all its children when it is destroyed. This is particulary important in C++, in Java with Garbage Collection it is somewhat less important.
The Gang of Four books also presents a full example of the application of the Composite Pattern, that I will not copy for copyrights, but you can find a lot of Composite Design Pattern examples in Google. If you want to see the GoF examples you can always buy the book.
The strategy pattern
If you want further information about the introduction to design pattern I have summarized in this article, I suggest you to purchase the GoF book in the Amazon online store.