Developers enjoy using this pattern, as it can be used transparently and is also fairly flexible: as weâve seen, objects can be wrapped or âdecoratedâ with new behavior and then continue to be used without needing to worry about the base object being modified. In a broader context, this pattern also allows us to avoid relying on large numbers of subclasses to get the same benefits.
There are however drawbacks that we should be aware of when implementing the pattern. If poorly managed, it can significantly complicate our application architecture, as it introduces many small but similar objects into our namespace. The concern here is that, in addition to becoming hard to manage, other developers unfamiliar with the pattern may have a hard time grasping why itâs being used.
Sufficient commenting or pattern research should assist with the latter; however, as long as we keep a handle on how widespread we use the decorator in our applications, we should be fine on both counts.
Get Learning JavaScript Design Patterns now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
