--- title: "Design patterns: naming a solution that keeps recurring" description: "Design patterns describe recurring problems and arrangements of collaborating parts. Strategy uses replaceable rules; Observer notifies registered listeners. Their shared contracts help keep changes b" canonical: https://lightmysky.com/learn/computing/design-patterns-naming-a-solution-that-keeps-recurring-mt_bhUEk8PwBp source: https://lightmysky.com/learn/computing/design-patterns-naming-a-solution-that-keeps-recurring-mt_bhUEk8PwBp.md retrieved: 2026-11-12 --- > **Agent view.** This is the Markdown twin of the page, for tools and assistants. > When to use this site, and the call that answers each job: https://lightmysky.com/agent-instructions.md > API description (OpenAPI 3.1): https://lightmysky.com/openapi.json · Authentication: https://lightmysky.com/auth.md > Pricing: https://lightmysky.com/pricing.md · Catalog: https://lightmysky.com/llms.txt · Full catalog: https://lightmysky.com/llms-full.txt > Every machine-readable file on this domain: https://lightmysky.com/.well-known/ai-catalog.json > Ask for Markdown with `Accept: text/markdown`, a `.md` address, or `?mode=agent`. # Design patterns: naming a solution that keeps recurring Design patterns describe recurring problems and arrangements of collaborating parts. Strategy uses replaceable rules; Observer notifies registered listeners. Their shared contracts help keep changes behind a boundary. Choosing a pattern means comparing its benefit with the extra structure it adds. Subject: Computing · Area: Software Engineering · Ages 19 to 21 Page: https://lightmysky.com/learn/computing/design-patterns-naming-a-solution-that-keeps-recurring-mt_bhUEk8PwBp ## Ready when they can - 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 ## Lesson: Names for solutions that keep recurring You have used interfaces to describe what callers may rely on. A design pattern describes a recurring problem, an arrangement that addresses it and the conditions where it helps. Its name gives a team shared vocabulary for the roles and tradeoffs. Recognising that arrangement does not prove its implementation meets the requirements; those still need checking. **Example.** Strategy delegates behaviour to a replaceable rule with a shared contract. In Python, rule = standard_rule selects an object; rule.fee(amount) calls it. After rule = reduced_rule, the next rule.fee(amount) uses the replacement. Both rules must keep the same inputs and promised behaviour. They need not inherit from one parent. For a few fixed cases, a short conditional may be easier. *(drawing: Read in order. The same call uses the rule currently selected. Both rules must keep its contract.)* Singleton restricts construction to at most one instance of a class within a stated scope, such as one running process, and provides access to that shared instance. It concerns objects, not how often the class is declared. A process-local Singleton does not automatically share its object with another process. Needing one object does not by itself make Singleton the best design. Observer lets listeners register with a producer. Each listener provides update(value). When a sensor's value changes, it calls that method on each registered listener. A new display can register without adding display-specific code to the sensor. The sensor knows listener references and the notification contract, but need not know their concrete classes. The contract must specify any timing or failure-handling requirements. *(drawing: This trace follows one registered listener. Other registered listeners receive their own calls.)* Object composition builds behaviour by holding and using other objects. It is a technique used by several named patterns, not one fixed class arrangement. An account can delegate sending to a sender and storage to a store. If retry logic changes inside the sender while the whole send(message) contract stays unchanged, the account can keep its call. Changing the contract may require caller changes. Naming a repeated setting is a reuse technique. In Python, LIMIT = 14 followed by saved = LIMIT gives saved the integer 14. Later, LIMIT = 22 leaves saved at 14. To refresh saved, run saved = LIMIT after that change; it then holds 22. A copy made before the change keeps 14. Checks that need the current setting can read LIMIT directly. Reassigning a name does not update earlier copies or rerun calculations. Compare a pattern's benefit with its extra calls, objects and maintenance. A replaceable rule can help when behaviour varies or needs separate testing. If one direct function meets the requirements and no replacement or separate testing is needed, swapping layers have no stated benefit. Other patterns solve other problems, so judge the particular arrangement against the actual requirements. **Recap.** Pattern names describe roles and tradeoffs. Keep shared contracts, state a Singleton's scope, and check how each extra layer helps meet the requirements. *Lesson, questions and flashcards written for this dataset. Textbook and academy records were consulted for concepts and question design; their wording is not reproduced.* ## Practice 8 questions on this page, each with its working shown. ## Needs first - [Interfaces, coupling and what a module promises](https://lightmysky.com/learn/computing/interfaces-coupling-and-what-a-module-promises-mt_EUZyD26WFk) ## Optional connections - [Inheritance and Overriding Behaviour](https://lightmysky.com/learn/computing/inheritance-and-overriding-behaviour-mt_wBp7j_B6fj) ## Opens up - [Refactoring: Changing Structure Without Changing Behaviour](https://lightmysky.com/learn/computing/refactoring-changing-structure-without-changing-behaviour-mt_HHZufOyTg4)