Breaking Down Design Patterns: Decorator Pattern
Since I am learning too, the patterns I am choosing to talk about are those that I have studied a little. They aren't related in any real sense other than that they are all design patterns. The pattern I am going to talk about in this entry is the Decorator pattern.
As with all patterns, the decorator pattern has grown from common practices among programmers. As such, the way it is used varies among those in the community. Unfortunately limitations in different languages often can affect which patterns are feasible to use in a given situation. The decorator pattern for example is made much more useful when the language allows the object to have multiple inheritance, or in other words, allows a piece of code to use pieces of code in other files, programs, or if you are official, classes.
In ColdFusion, we are in one of those situations where we are somewhat limited by the language's lack of multiple inheritance. Often, multiple inheritance is more trouble than it is worth in that it can lead to lazy messy code and can make software harder to debug. ColdFusion's single inheritance is more than enough for most web applications, even those being built to enterprise standards, however it can cause you to write more code, and make your objects more reflective. When you hear someone talk about an object as being reflective, it means that it knows about itself, like if an XML object knows that it contains the entry dates for transactions of a sort, then it can tell other objects what it knows. If those objects are reflective, then they can decide if they want to use the XML object's information or not. This may not be the best analogy, but I think it works.
Back to the decorator pattern. The decorator pattern is implemented when it is necessary to extend an object's functionality in some way for a particular job, but if the extension is not one that you want applied permanently. In ColdFusion, one way to easily implement the decorator pattern is to have a decorator cfcomponent use the extends attribute. This way the extended component's methods are available for the decorator object to extend. Another way to handle this is to allow the decorator object to perform post-processing of the response from a more basic object. Use of the decorator object, off the top of my head, is a good way to extend the functionality of a particular crud object. For example if you have an object that inserts some data into a table, but you want for a particular situation to copy that data into another table. You can write a decorator tied to that situation that will take the affirmative completion of the create function to execute another create function for another table.
Design pattern's are not that complicated, it is easy once you begin to think of your chunks of code as entities with responsibilities. Then you can build the chunks (classes) to perform tasks that are explicitly tied to the object's job. With planning, your code will automatically become more granular because you can't have a single object doing too many jobs, because then it is more difficult to make that object general enough to help out other objects with their jobs, which is, at its base, the goal of Object Oriented Programming; to make reusable chunks of code.