Decorator Pattern
Decorator: start from the problem
See the responsibilities
A text formatter needs optional capitalization and a label. Creating subclasses for every combination ties independent options into a growing inheritance tree.
This is a structural pattern lesson. Follow the responsibilities, inspect the small JavaScript example and compare the design choices. The example is local teaching code; its boundary is explained before you apply the idea to a real service.
What you’ll learn
- Explain the problem Decorator addresses and the roles involved.
- Follow the example and distinguish this pattern from nearby alternatives.
- Choose when the benefit justifies the extra responsibilities and testing.
How the responsibilities work
Decorator wraps an object through the same client-facing contract and adds behaviour around delegation. Several wrappers can be composed. The inner object remains usable through that contract, while the order of wrappers determines the resulting behaviour.
Our formatter returns text. One wrapper uppercases the inner result; another prepends a label. Reversing those wrappers changes whether the label is also uppercased.
Follow a small example
Read the JavaScript from top to bottom and compare the expected output. The values are chosen to make this pattern’s responsibility visible. This example runs in one local execution context; it does not create remote services, durable storage or production access controls.
JavaScript · local teaching example
const plain = {format: text => text};
const uppercase = inner => ({format: text => inner.format(text).toUpperCase()});
const labelled = inner => ({format: text => 'note: ' + inner.format(text)});
console.log(labelled(uppercase(plain)).format('hello'));
console.log(uppercase(labelled(plain)).format('hello'));Expected output
note: HELLO
NOTE: HELLOChoose a design and inspect the consequence
Compare the design choices
Compare the visible consequences. With JavaScript enabled, choose an option in each scenario to assemble your decision record.
This is an exploratory design exercise. It does not run infrastructure, measure capacity or replace the lesson’s quiz.
Apply the pattern to two situations. Select one option in each situation to build a decision record. Every option and its consequence stays visible, and you can change your choices.
When it helps—and what it costs
Use it for composable responsibilities such as formatting or instrumentation when the wrapper can honestly preserve the client contract.
Wrapper order can affect errors, caching and output. Too many layers make traces hard to follow. A wrapper that changes required semantics may violate the original contract even if it has the same method names.
Distinguish the neighbouring patterns
Proxy primarily controls access or indirection to a target. Decorator adds responsibilities. Chain of Responsibility routes a request through handlers that can pass or stop it.
Follow Proxy’s access and indirection, ordered request handlers, instrumentation responsibilities to compare the specific responsibility before combining patterns.
Check your pattern reasoning
Check your pattern reasoning
Name the responsibility before choosing the pattern
For Decorator, describe the problem, the participating roles and the observable contract. Use the example as a starting point and test the boundaries identified in the trade-offs. A pattern name alone does not establish correctness or performance.
Return to the design-pattern guide to compare families, or apply the idea alongside instrumentation responsibilities.
Reaching the recap and completing the quizzes are separate milestones.