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.
Last week, on my blog, I discussed simple and static factories briefly. That post, however; only talked about some of what factories can do. This week, to round off my knowledge, I choose to reaffirm learn more about abstract factories. The best resource I found to help me with the topic was oodesign.com (Object oriented design). Above I’ve linked all three of their pages on factories but I’ll mostly be concerning myself with the last one, abstract factories. For the most part, I can earnestly say I didn’t know much about abstract factories. I’m not the most well-read developer, yet. But immediately they seemed like an impressive tool.
From my readings and class lectures this week, I know that Factory Method pattern uses an interface to create objects while allowing for subclasses to decide the type of object. I learned though, that abstract factories were an extension of this functionality. They are essentially a factory of factories that allows us to take advantage of the “code to an interface” principle.
I can immediately recognize that abstract factories prove a good practice to code. In the pages, I saw that every subclass had their own factory classes written for them (meaning that factory method pattern and abstract factories work well together). Subclasses can be added to an interface, so long as they are compatible (in the same family of objects). This would seem to promote easier refactoring and extending functionalities of programs. And, as a developer, I assume that any program I write will need to be expanded or edited. If abstract factories truly do make it easier on that front, then I’d be more than willing to use them. Unfortunately, I do have a concern relating to their extendibility.
They aren’t entirely flexible, that is, an abstract factory can’t help creating in an object that isn’t in the same family. The added abstraction and encapsulation seems like it would start to become overly complex or cluttered for it to be easily read by humans. With every interface having multiple subclasses and factories, any UML diagram or visual would start to get cluttered or cumbersome if a program has multiple interfaces that create families of objects. Making the code more efficient and organized doesn’t mean we’re making it easier to read. We should remember that it’s humans that will edit our work after all. Though, since it seems like factories in general are prevalent, I’m sure I’ll become practiced enough that they aren’t daunting. I just don’t want to be the guy who makes someone else’s day difficult because his code is hard to read.
Using abstract factories also avoids using conditional logic, it seems. The usual factory design pattern would use if statements or switches to decide which subclass to return but, as I said before, each subclass has its own factory. The abstract factory then returns the subclass depending on the input factory class. Conditional statements aren’t necessarily difficult to write and understand. The appeal to avoiding them, to me, is avoiding certain errors all together. I have less to worry if less of my code can throw an error. Also, if the program were of a larger size, there may be a so many conditions that writing a case or if statement for everyone would become painstaking. Being able to avoid errors and making code easier to write is an attractive feature.
Just like the other factory patterns, I can see there is a place for abstract patterns in the workplace. Now I just want to be sure I know when and how to use them. I’ll certainly be practicing with them.
This week’s blog, as with the last, will be about a topic directly covered in class. And, more importantly, it’ll be necessary knowledge for the first assignment of my class making it a good choice to review. The above linked article is about factory design patterns. In class, we only covered the use of simple factories whereas this article covers factory method pattern, abstract factory pattern, and static factory methods as well. Since I have a length limit, I’ll cover the most pertinent material first while focusing on things I learned outside of the classroom about their use.
Starting with the Simple Factory first. The author informs us that a simple factory isn’t considered a pattern technically but notes that it’s prevalence requires covering. They describe it as a tool that can be “to create/instantiate objects,” but it’s one that is rarely used. More commonly a static factory would be used in java. If the developer’s “factory method needs some instances to work” or “they need to instantiate the factory in order to use it,” then the simple factory works fine but a lazy static factory is still advised.
Since Static Factories are more resourceful it seems, lets discuss them in more detail. The first use he notes is the static factory’s ability to replace a constructor to “create an instance. The first advantage I see from this is the fact that factories have names. Any unique constructor name can only be used once in a class. Any time a class would need multiple constructors with the same name, static factories can be used with more descriptive names to help anyone reading/working with the code. Another convenience of static factories, as opposed to constructors, is that it doesn’t have to create an object when invoked. This helps reduce creating duplicate or unnecessary objects. One last noticeable boon is its ability to have stricter control over what instances exist. Relating to the previous blog, this helps guarantee that a class is a singleton.
Although this concept was already covered in class, its importance requires mentioning. A factory can return any subtype of its return type. This, overall, adds great flexibility to the programmer.
The author does advise that factories (and most patterns) should only be used when necessary as they can make the code more difficult to understand. Small personal projects most likely don’t require them but, they find good use when working in large projects.
This information, complimented with examples, was instrumental to my understanding of factory use and implementation. Using factories seems like a great practice, when done appropriately. It also is obvious that this is a core tool that I’ll need to have as a developer. I know that this will be applicable to my immediate work. But, beyond that, I’ll probably be using it on any project that requires me to create multiple instances of an object. Especially when that allows me to avoid having to write nearly identical constructors repeatedly. (Factories seem awesomely useful and a huge time saver.)
Seeing as we’ve started learning about design patters in class recently, I decided I’d explore a pattern further in depth. Seeing as the singleton pattern was the last covered in class it was the one I chose. Where most other sources would just condemn it as a bad practice, the article linked above does a good job of exemplifying both the pros and the cons of using the singleton design pattern. One of the pros, something I learned as well, was how singleton classes can save memory by using lazy instantiation. Opting not to assign memory to the variable until called; this method can create errors as well. If multiple threads access the instance at the same time it will create multiple instances of the singleton class. There are synchronizing techniques to get around the issue but it’d most likely be easier to use static initialization. In static initialization, memory is allocated when the variable is declared. The only difference this makes in the code is moving the creation of the object to where the variable is being declared. Inheritance with singleton classes seems straightforward enough. Any class inheriting from it will create more than one instance of the class thus violation the principle that only one instance can exist. However, if you wanted multiple singletons to inherit the same behavior, the code could be provided in an abstract class. Although this may seem purely a shortcoming, it does prove itself when compared to static classes inability to work from interfaces. One of the other major drawbacks that I learned about was that singleton classes couldn’t accept parameters which contributes to their limited flexibility.
The singleton pattern has me a bit conflicted with its use in java. Although it seems like an easy way to create global variables in java, many of its drawbacks seem very limiting or painstaking with more complicated programs. The linked article does, however, do a great job of showing and explaining how to create singleton classes and will differently be my go to for a reference. Reading it was a great auxiliary to the lectures given in class. Seeing how singletons work (and don’t), in depth, has also raised my confidence with working with them. I’m sure that having a complete understanding of this design pattern will be useful as a tool to compare and understand the behaviors of other patterns.
Jenkov’s article is about a core concept of java and other object-oriented programming languages; interfaces. As basic as the concept is to programmers, it’s important to have a full understanding of such core concepts. And that’s where I think this article excels. It does a great job at making the information much more learn-able, digestible. Far better than the oracle libraries, Jenkov explains how to implement and work with interfaces in projects. His article does a good job of explaining what’s in the examples and code. The first he speaks of, after what an interface is and how to implement it, is implementing multiple interfaces. Unimpressive it may be, but it helped me. It’s not like the code was hard to learn or understand. It’s just a huge help to how I learn to see everything completely explained. Just looking at an example isn’t always helpful to me. Although in the case of implementing multiple interfaces, it would have been.
Beyond just what we can do with interfaces and inheritance, he explains how interfaces relate and operate with core concepts in object-oriented programming. Opting to discuss the usefulness of interfaces as well as how to implement them. This portion of his work was most beneficial to me. To not only know how to create interfaces but to also know how to use them effectively. Paired with his explanations, he gives examples of good coding practices with interfaces. But he doesn’t explain only what interfaces can do. He also warns of the short comings of interfaces.
Sure, they are awesome examples of polymorphism in programming but, they can be broken. One of the things to be cautious of is having overlapping method signatures. Something I learned; Java classes can only implement a method with a given signature once. Thus, having the same signature in two interfaces is a problem. However, it shouldn’t be too much of a pain as long as the programmer remembers what they’ve already written.
Another great lesson I got from this writing was on how inheritance can work with interfaces. I hadn’t known before that interfaces could inherit from one another and any class inheriting from a child interface got everything from the parent as well. The article gave me a good overview on how interfaces work as well as ideas and understanding on how and when to use them.
This blog was created as a requirement for a college coarse and will be used to share my analysis of computer science related articles, blogs, etc.