Skip to main content

Decorator Design Pattern


For this week's blog on Software Design, I decided to watch a short tutorial on one of the design patterns I didn't pick for a previous assignment. I picked Proxy Design pattern to cover before, and now I'm going back to learn about Decorator Design Pattern. It is only a thirteen minute video, so I won't be going as deep as I would had I picked it for the assignment. I am also going to talk about my reflections on it rather than create a tutorial, so I am not going to reteach it to the person reading this blog post.

The tutorial I chose was made by Derek Banas on YouTube. He used an example of a pizza parlor to illustrate the wrong way to code it by using inheritance. He shows the problem with this because you would have to create a very large number of subclasses for all your objects (in this case pizzas).

Composition, on the other hand, is a dynamic way of modifying objects. Instead of creating as many subclasses, you add functionality at run time. It has the benefits of inheritance, but is better to implement in many cases because it is more flexible. Instead of rewriting old code, you extend with new code.

This seems like a more intuitive way of doing things. In the example in the video, he uses the example of creating different kinds of pizza. If you were to design a menu for the same pizza place and there was twenty ingredients and different prices for each, it would make more sense to list the cost of the sizes “Small $5, Medium $7, etc.” and the prices of the toppings in a similar way, with Pepperoni and Sausage being 50¢ and 65¢ respectively. The customer would then choose the size and toppings and add all those together to get the total price.

It seems like the decorator does exactly this. It would seem silly for a pizza shop to list every permutation of toppings and sizes. It would make sense if there were only a handful of pizzas to choose from, but it does not make sense to do this if there are too many ways to list. Same with inheritance instead of decorator design pattern. The same logic is true with inheritance. This seems like an incredibly useful and versatile tool to use. I think learning about this will be incredibly invaluable for the future.

http://www.newthinktank.com/2012/09/decorator-design-pattern-tutorial/
Labels:

Comments

Post a Comment

Popular posts from this blog

Sprint 5 Retrospective (Capstone)

It is a shame that we are so close to the end of the semester. We were gaining so much momentum. It took us a while for us to get off the ground, but once we did, we never stopped gaining speed. I feel we will be able to keep this up through this last sprint. My hopes at the beginning of the semester for what we could accomplish were unrealistically high, but I am not disappointed with what we accomplished. We have not completed a full working component quite yet, but we are very close. I think our efforts are best spent finishing the one we are currently working on and doing it right. If we divided our efforts into starting something new, we run the risk of not fully completing anything. In the sage words of Ron Swanson, “Never half-ass two things. Whole-ass one thing.” If we are able to get the tabs working beautifully, I will be happy with our effort. I have felt that our group has done a phenomenal job this sprint and every sprint before with our communication. We have a few ...
Post a Comment
Read more

Mark Richards on the Evolution of Software Architecture

For this week’s blog on Software Architecture, I listened to Episode 3 of the “Software Architecture Radio” Podcast, which featured Mark Richards, an independent software architect. He has 32 years in the industry, with more than twenty years as a software architect.  They mostly talked about the evolution of software architecture. Although some of the things they talked about went a little over my head, I was able to pick up on the majority of what they were talking about.  He divided up the evolution of architecture into five stages. He talked about evolution happening in vertical and horizontal slices, that is within each layer and one layer affecting those above and around it. The layers were (1) hardware, (2) software, (3) human interaction, (4) social interaction, and (5) the environment, such as the internet of things. He said one thing in particular, need, drives change the fastest. As an aside, he also said that that’s the best way of teaching something i...
1 comment
Read more

Sprint 4 Retrospective (Capstone)

This sprint, in my mind, one of the most important things that I was able to figure out was getting connected to AMPATH team through the Zeplin app. It seems that someone, perhaps accidentally, disconnected me from the group. Once reconnected, I was able to connect the rest of my group. Although it hardly was a difficult task, it is hard to overstate how important it is to be on the same page as the team you are building the product for. It could have prevented a lot of wasted time on our end, and it makes it more likely that they get the end product they want. Probably the most important thing I did in terms of learning about the tools we will be using was creating a “spike.” It is a new term I’ve learned that I will add to my lexicon, meaning to build a prototype of a product, diving deep to learn as much as you can. I touched upon it in my last apprenticeship patterns blog post, on “breakable patterns.” I failed to make a successful working prototype that did everythin...
Post a Comment
Read more