A good programmer and software developer will create code and software that is easy to maintain and modify. When problems arise, issues could be taken care of fairly easily. But sometimes, the easiest solutions are not the best ones, it could make the software more difficult to maintain or change. Using design patterns can help identify these issues and show some solutions to those issues.
In class, we worked with a few design patterns, specifically the strategy design pattern, the singleton, and the simple factory pattern. Each one does something a little different from each other, but they help make things organized in a sense. We used them all together, implementing each one by one, but each could be used separately.
In this blog post, Giridhar Talla writes about design patterns, and describes them as an “existing solution.” They define design patterns as “solutions to commonly occurring design problems in developing flexible software using object-oriented programming.” Design patterns can vary, and can be grouped into 3 groups, creational patterns, creating objects to increase code flexibility and reuse, structural patterns, turning relations between objects and classes into complex structures, and behavioral patterns, defining how objects communicate with another. The specific design patterns Talla goes over are the singleton design pattern, the decorator design pattern, the strategy design pattern, the state design pattern, and the command design pattern. Each pattern is unique in its own way, flexible and simple. After reading, I found the state design principle very interesting. Instead of a lot of conditional statements, you could create multiple states. The user can change how the application works at runtime, which allows you to design finite state machines. I find this cool and unique, as it is something I have not personally done, but the concept seems really interesting.
A good programmer should be able to create reusable and extendable code, it is just good practice. Design patterns can help you make them flexible and maintainable. I chose this blog post because I thought design patterns were really useful and interesting, and I wanted to learn more about other kinds of patterns. Since design patterns are somewhat recognizable due to their reuse, it is not hard to explain unseen software to people who have not looked at it before. Even if it is done wrong, it will help you or a team understand what is wrong with the overall thing, and then from there, you can apply the correct one. I am fairly certain that I will be using these in the future.
From the blog CS@Worcester – Cao's Thoughts by antcao and used with permission of the author. All other rights reserved by the author.