Why Design Patterns and Algorithms Aren’t Part of Official Language Specs

Why design patterns and algorithms are not part of language specifications

Generality vs language-specificity – Patterns and algorithms are language‑agnostic; language docs focus on syntax, semantics, and built‑in libraries.

Flexibility and evolution – Embedding a fixed set would hinder community‑driven innovation; keeping the core minimal allows new patterns to emerge without breaking compatibility.

Maintenance burden – The corpus of patterns grows continuously; updating an official spec for each addition would be impractical.

Modeling patterns with UML

UML class diagrams can capture the static structure of a pattern, while sequence diagrams can illustrate dynamic interactions. For the Observer pattern the typical UML elements are: Subject – an interface or abstract class that defines attach(observer), detach(observer), and notify(). Observer – an interface with a single method update().

ConcreteSubject – implements Subject and maintains a collection of observers.

ConcreteObserver – implements Observer and registers itself with a ConcreteSubject.

A minimal UML class diagram can be represented as:

+----------------+          +----------------+
|   Subject      |<>------->|   Observer     |
+----------------+          +----------------+
| +attach(o)     |          | +update()      |
| +detach(o)     |          +----------------+
| +notify()      |
+----------------+

ConcreteSubject --------------| implements
ConcreteObserver --------------| implements

Sequence diagram example (simplified):

Subject.notify()
    -> Observer.update()
    -> Observer.update()
    ...

These diagrams help developers visualise responsibilities and collaborations without relying on language‑specific documentation.

Practical example

Below is a concise implementation of the Observer pattern in Python that follows the UML structure described above:

class Subject:
    def __init__(self):
        self._observers = set()

    def attach(self, observer):
        self._observers.add(observer)

    def detach(self, observer):
        self._observers.discard(observer)

    def notify(self):
        for observer in self._observers:
            observer.update(self)


class Observer:
    def update(self, subject):
        raise NotImplementedError


class ConcreteSubject(Subject):
    def __init__(self, state=None):
        super().__init__()
        self.state = state


class ConcreteObserver(Observer):
    def __init__(self, name):
        self.name = name

    def update(self, subject):
        print(f"{self.name} received state {subject.state}")

# Usage
subject = ConcreteSubject(state=42)
obs1 = ConcreteObserver("A")
obs2 = ConcreteObserver("B")
subject.attach(obs1)
subject.attach(obs2)
subject.notify()

This code mirrors the UML diagram: Subject manages observers, Observer defines the contract, and concrete classes provide specific behavior.

Conclusion

Design patterns and algorithms remain external to language specifications to preserve flexibility, encourage community evolution, and avoid constant spec churn. UML and concise code examples provide a language‑agnostic way to document, understand, and implement these patterns across different programming environments.