We attach labels to everything, in order to recognize it’s value, and communicate ideas. There is a programming discipline that loves something called patterns. Yes, jargon can sound pretentious. Composition is the “pattern” of what most of us do. We put together different components, with different interfaces together to produce a new one.

Think of this as a glossary page. It explains nothing about how version 1 of the Google Maps Webservices Proxy classes work. This is for stupid.

I called composition the “bastard child that no class wishes to claim kinsmanship with”. Make no mistake, “bastards” are how most of the programming in the world is done. There is no universal adapter. But if there was a place where a universal adapter could be used w/o side effect, would you use it?

To understand how this “kinsmanship” works, you have to understand inheritance. I fear you may not, so I added this post as a “Surgeon General’s warning” that decorators aren’t to be used everywhere. Just like you should need a sticker to tell you cigarettes give you cancer. The usual implementation of decorators is inheritance of interfaces, which is a similar abstract idea to inheritance of classes, so the metaphors below should be appropriate. Below is a diagram that depicts the abstraction of an idea of a program that has a reference to a base class. The caller’s “shape” perfectly matches the base class’s shape. This is an metaphor for the instructions used to call the base class, working perfectly with the implementation of the base class. Inheritance, as a metaphor, is an extension added to that shape, that doesn’t affect how it “fits” with the old shape. So the same instructions work on the old parts.

In case you don’t know what inheritance is. Smaller yellow shape is the base class in our metaphor. It fits the red shape like a key, which is our metaphor for code that perfectly invokes yellow. The larger yellow shape is a class that inherits from the smaller yellow shape. The common denominator in shape is the metaphor for inheritance. The metaphor works b/c red shape will still fit perfectly in the “common denominator” areas.

It also occurred to me that you may not know what decorators are. Using the same metaphor, the figure below depicts how decorator’s design can be used to seamlessly add and remove functionality in runtime, without requiring re-compilation. Since the same “shape” exists, the same instructions will work on every class, but executing different functionality. Therefore the stack can have different parts without re-compilations, bc the instruction to invoke each part is the same.

It shortens the code needed to call different options, if possible at all from a more rigid design using composition

How this differs from composition with the same functionality, can be observed in figure below.

The dependencies are rigid, so even if you wanted to have different options, you would have to have code for every permutation for the different optional functionalities. Additionally, it creates a different mindset. Think of the shapes as different ports for your smartphone. If they are same, you assume you can plug anything with same port into them. If they are different, there may be a incompatibility reason.

Each class that has a function, has a different “shape” or set of instructions to invoke it. The program cannot use the same set of instructions to invoke the proxy class, as the caching class anymore. If the user wanted to check a checkbox in “Preferences” to bypass caching here, he needed to write code to specifically invoke the proxy class.