Design Patterns: Naming a Solution That Keeps Recurring
Some arrangements of objects appear again and again: swapping behaviour at runtime, telling listeners something happened, hiding the choice of which class to build. Naming them gives a team shared vocabulary, and the risk is reaching for a pattern where a plain function would do.
What a learner can do afterwards
- Recognise the strategy arrangement in code that does not use the word
- Apply the observer arrangement to decouple a producer from its listeners
- Give an example where a pattern adds indirection without buying anything
1 · Read
A pattern is a written note about a problem that keeps showing up, plus a solution that worked before in that kind of situation. Its name gives your team one shared word for a whole arrangement.
Code that swaps its behaviour at runtime by holding a swappable piece is the strategy shape, even when the word never appears. Code that must exist only once in the system is the singleton shape. Spotting means asking what arrangement of objects is really going on. Name a fixed value once and refer to the name everywhere, so one change updates every use.
The observer shape decouples a producer from its listeners: the producer tells whoever listens that something happened, without knowing them. The composition shape builds one object from smaller ones with one job each, like an account holding a sender and a store, so a later change touches one small part.
A pattern is never a magic ingredient you must always add. Where a plain function does the same job with less fuss, the pattern only adds indirection without buying anything, so part of knowing a pattern is knowing when not to reach for it.
Learn each name as a shared word for a recurring shape, then use it only where it buys you something.
2 · Watch
Take it off screen
Where it sits
8 questions wait behind this lesson, each with its answer explained. Every answer feeds the sky: stars light as they are learned, and dim when it is time to come back.