---
title: "Design Patterns: Naming a Solution That Keeps Recurring"
description: "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 voc"
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-09-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

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.

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

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.

**Example.** 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.

**Tip.** 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.

**Recap.** Learn each name as a shared word for a recurring shape, then use it only where it buys you something.

## 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)
- [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)