Design Patterns in Go: Decorator

decorator pattern

Structural patterns focus on the organization of code, components, or interfaces. They address issues like managing object relationships, providing abstraction from underlying implementations, or integrating different libraries and frameworks into a cohesive system.

OK, Let’s go through the description of the 4th structural pattern — Decorator.

Context:

You want to augment or alter the functionality of objects at runtime.

To extend the base class is a solution, you could augment or alter the functionality of base class. But inheritance has some serious ceveats, that you must know:

• Inheritance is static. You can’t alter the behavior of an existing object at runtime. You can only replace the whole subclass object with another one that’s created from a different subclass.
• Subclasses can have just one parent class. In most languages, inheritance doesn’t let a class inherit behaviors of multiple classes at the same time. (C++ supports multiple inheritance, while most languages don’t)
• The class to augment or alter may be maintained by 3rd party, or is going to be deprecated … In a word, it’s not that easy to modify it, so we don’t want to devote more time on to it.