In the last lesson we looked at patterns in general and why we might want to use them. So here is our first pattern. We are well on our way to creating a common language with which to talk design.
One of the reasons I picked this pattern to start with, is that it is very easy to understand. It models real word situations very well, and that is what OO design is supposed to do right, model real world objects?
The Adapter in the Physical World
The concept of an Adapter is easy to understand. It does just what it is named to do. It adapts one object to that of another. Take the wall plug. It has three rectangular holes set at angles to fit the plug. It does? In Europe it does. We are traveling and need to plug our laptop into the wall. What do we use? An adapter.
The Adapter in the Software World
The idea is not so different in the software world. When you want to connect one class to another class that was not designed to fit together, you need an adapter class. Let’s look at an Java example to see how we can adapt one class to another.
The last pattern we looked at was the Adapter pattern. It was a good pattern to start with as it maps well to the physical world and is fairly simple. Now we will look at the Singleton pattern. In some respects it is the simplest of patterns, but there are some things to think about.
The Singleton in the Physical World
The idea behind the Singleton is to ensure that there can be only one (insert Highlander jokes here). If you had a factory that made widgets, you would want a widget to be created many many times. But there is only one factory. If you were modeling the US government, you would only want one president. Only one senate.
The Singleton in the Software World
On the software side, the idea is the same. It is usually used when we only want one set of configuration variables, one controller, one data base connection pool, that kind of thing.
We have looked at the Factory, the Adapter, and the Singleton patterns. Now we look at the Decorator. The Decorator is similar to the Adapter, but with a subtle difference. With our ReptileAdapter, we wrapped the Reptile class to map the interface methods of Animal to the appropriate methods on Reptile. With the Decorator we also wrap a class, but to add functionality, not to map it or replace the functionality.
The Decorator in the Physical World
The idea behind decorating things in the real world is pretty much how it sounds. We wrap an object with new functionality, while keeping the old functionality. How about a camera in a waterproof housing? When closed up, we have added the functionality of waterproofing, but we still provide a way to press the buttons and turn the dials so that the camera can be operated.
The Decorator in the Software World
On the software side, the idea is the same. It is usually used when we have one object that we like how it functions, but we want to augment the behavior for a different situation. Done correctly, we can keep inserting one object inside another adding functionality at every step.