Thank you for the article. It’s clear you have put a lot of thought in to it. This is the second article I’ve read that tries to use real world objects to demonstrate the decorator pattern. A previous article used cakes with various toppings.

I understand the decorator pattern principle but it’s usage in this case isn’t practical and so I believe trying to describe it in this way is ultimately confusing. Nobody would build a billing system where all the menu items were represented as classes. Trying to explain it this way just creates a problem that never existed in the first place, and therefore didn’t need the decorator pattern to solve it.

I’d like to know how the decorator pattern provides any benefit over simply using an interface? Assuming someone were crazy enough to create a class for every type of product, wouldn’t it make far more sense to just have an interface for getCost() and getDescription() ? Multiple products (such as a coffee + sugar + milk) would be an array or similar. Perhaps you have another example that works to solve a real world problem?

Written by

I’m a data nerd and TDD enthusiast originally from Sydney. Currently working for Uber in New York. My thoughts here are my own. 🤓

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store