This short blog post discusses the uses, design, and implantation of the decorator design pattern. Specifically, in java. There are two reasons I chose to write about this topic. Firstly, I’m currently doing an assignment on the subject but, more importantly; Decorator pattern is one of the first ones covered in “Head First Design Pattern” (Freeman, Bates). I’m assuming that this means it is one of the more basic ones we should understand as developers. (Again, I’m still in school, I may be wrong) The reason I chose this blog in particular is because it’s example code is explained well and its example is more suited to what decorator pattern can do. I found the aforementioned text’s example a bit ill suited.
The blog’s example is to create a basic ‘IceCream’ object that has toppings applied at runtime. Decorators achieve their flexibility by creating wrappers to go around objects that communicate between the object and system. Decorators can also wrap wrappers that are already applied to an object. To do this, a decorator class is created that implements the same interface as the object we want to modify. From there, two concrete, decorator subclasses are created that can make the modifications the user or developers want. In this case, it’s adding nuts and honey.
From this blog I learned that the main advantage of decorators is “changing the behavior of an instance of our choice at runtime” which adds a great deal of flexibility to our project. This seems like a great alternative to what can be referred to as “sub-class explosions.” In other words, this is a good way to avoid having too many subclasses. This may not be necessary for the machine but, it’s a boon to the humans who have to work with the code.
The decorator pattern, from what I can tell, will most often be used when inheritance is either impossible or unreasonable for whatever reason. As I stated before, avoiding sub-class explosions is the most likely scenario for the later likely use of Decorator.
To me, this pattern seems fairly simple to understand and implement which excites me because that will make writing and practicing much less painstaking. My only gripe with this pattern is that, although it adds flexibility to our code and can reduce sub-class totals, that’s all it does. Of course, patterns are going to be one-dimensional because they are designed to tackle a single problem but, I’m not sure if there will be a lot of use of the decorator pattern in professional projects. That is, the problem it solves doesn’t seem too common or obnoxious. However, I enjoyed learning about it nonetheless because, for me it’s fun to solve issues of any kind.