66: Design Patterns: Composite.

The composite structural pattern allows you to build elaborate objects from smaller objects and not worry about how big they get. You can treat your composite objects as if they are all the same. If you have hierarchical data, then consider this design pattern as a way to help you work with objects that represent roots of the hierarchy without worrying about if there is just a single item in the hierarchy or thousands. You start out with an abstract class that allows you to treat all the classes participating in this pattern the same. We’ll call this class a Component. Then let’s say you want to represent a file system with files and folders. All you need to do is define methods in the Component class that will be common for files and folders. Then declare the File and Folder classes to each derive from the Component class and override the methods that make sense to them. Some of the methods may only apply to files, some only to folders, and some methods may apply to both. The Folder class will be most interested in the child manipulation methods. Each of these methods will work with Component instances so that you can add a File or a Folder with the same method. This is the key to this pattern – being able to treat all the objects as if they are of the same type. A file system example follows the hierarchy very well, but it may not appear at first to be the best example of this pattern because files and folders usually behave very differently. It can still work as an example as long as you remember that what you see as the end user of an application doesn’t always match what the code sees. The code can still treat files and folders the same even if it also displays them to you as if they’re different. Listen to the full episode or read the full transcript below. Transcript The basic description says that this pattern lets you compose hierarchical tree structures and then treat the individual objects and the compositions of those objects the same. You should consider this pattern anytime you have objects that can contain other objects which can then contain other objects etc. Think of your computer’s file system where you have folders that can contain files as well as other folders. Any folder no matter how deep it is follows these same rules and can keep containing more files and folders. Sometimes, there might be a limit imposed on this like how Windows machines have a maximum file path length but that doesn’t mean you have to add limits to your design. Sometimes files can behave like folders like when you navigate into a compressed file. This pattern doesn’t say that you can’t tell objects apart, just that you can treat them the same. Just because the code can treat files and folders the same doesn’t mean that the application needs to let the user do the same thing. Maybe you want to add a feature to your application that lets users compose notes by typing some text. You want the user to be able to add as many notes as desired. And you also want to let the user refine the notes by adding more details. Each detail will be another note. Well, once a note can contain another note, it’s just a small extra step to let a note contain many other notes. This is the basis for the composite pattern. All the notes are the same even if some of them could be rather large. I’ll explain how to do this in code right after this message from our sponsor. ( Message from Sponsor ) The first step to implement this pattern is to define an abstract class with methods common to everything you’re going to want to do with the items in the tree. Let me first say that I’m using the word tree here as a general description of the hierarchy. I don’t mean to imply this is a binary tree. Episode #41 describes binary trees. You’ll probably have two types of methods in your abstract class. Let’s call the abstract class the Component class. If your tree will