In the previous chapters you learned that objects can descend from parent objects via inheritance. You've also seen how objects can contain references to other objects, such as a DrumSet object holding Drum objects. In general, the technique of composing an object from other objects is referred to as object composition.
Both inheritance and object composition are powerful tools in designing object-oriented software and allow for a wide variety of design choices. Of course, having many choices does not always make decisions easier. How would you design your application so that it's easy to maintain and extend? How would you write a component that the other members of your team could use through a simple interface? When writing software, you can solve certain problems on your own using your experience, intelligence, luck, large doses of soda, or any combination of the above.
You've probably reused existing code of your own to solve a problem. Perhaps you have a standard script for connecting to a database. Design patterns are a bit different in that they are not simply about reusing code; they are more abstract and generalized than that. The same design pattern can show up in completely different types of software. Design patterns are about reusing ideas. After you know a pattern, you should be able to recognize where it would be useful. Then you can go ahead and implement it knowing that it's an accepted solution.
A design pattern is a specific way of solving a particular problem. In our case it represents the way an object or set of objects is structured, how they collaborate and communicate with other objects in the pattern. Each pattern has a descriptive name, such as Observer or Observable, and each pattern has a specific design that can be shown in a class diagram.
Patterns can be confusing at first. If this initial description doesn't seem clear, don't be concerned: You'll be working through five different patterns in this chapter, building on some of the code you saw in the last few chapters.