WS 5. Software Engineering Design Patterns

Comprehensive vocabulary flashcards covering the fundamentals of software design patterns, pattern languages, forces, generative AI design judgment, the Strategy pattern, and the Observer pattern.

Pattern (Software Engineering)

Reusable design expertise that codifies time-proven solutions to commonly occurring software problems arising within particular contexts and domains.

Design Vocabulary

A shared terminology established by patterns that enables developers, designers, and architects to name, document, and communicate recurring architectural structures effectively.

Known Uses (Rule of Three)

The requirement that a pattern must be verified to exist in at least three real, existing systems to confirm it is a time-proven solution rather than an unverified idea.

Forces

A system of conflicting constraints, non-functional requirements (NFRs), or quality attributes—such as memory, performance, costs, maintainability, simplicity, time-to-market, and reuse—that a pattern resolves to create a balanced solution.

Consequences (Pattern Component)

The documented positive impacts, negative side effects, and trade-offs that result from applying a pattern, enabling architects to evaluate whether a solution is suitable for a specific design problem.

Pattern Language

A collection of interrelated patterns that systematically guides the step-by-step application of multiple patterns in combination through an incremental refinement process driven by forces.

Human Design Judgement

The evaluation and reasoning applied by developers to analyze forces, consequences, and alternative approaches when reviewing, selecting, and adapting AI-generated pattern implementations.

Strategy Pattern

A behavioral design pattern that defines a family of algorithms, encapsulates each one, and makes them interchangeable, allowing the algorithm to vary independently from clients that use it.

Compositor

An interface in the line-breaking motivation for the Strategy pattern that declares a compose() operation, encapsulated across concrete algorithms such as SimpleCompositor, TeXCompositor, and ArrayCompositor.

Context (Strategy Pattern)

The class configured with a ConcreteStrategy instance that maintains a reference to a Strategy interface and delegates algorithmic execution to it rather than implementing the algorithm directly.

ConcreteStrategy

A class that implements a specific algorithmic variant or behavior declared by the Strategy interface (e.g., CreditCardPayment or PayPalPayment).

Dynamic Behavior (Strategy Benefit)

A benefit of the Strategy pattern that permits algorithms to be switched or substituted dynamically at runtime by providing a different concrete strategy to the context.

Eliminates Conditionals (Strategy Benefit)

A benefit of the Strategy pattern that reduces complex conditional statements (such as nested if-else or switch statements) in client code by isolating algorithmic variants into separate classes.

Client Awareness (Strategy Drawback)

A drawback of the Strategy pattern that requires clients to understand the operational differences among distinct strategies in order to instantiate and assign the correct one.

Stateless Strategy

A strategy implementation that stores no client-specific state, allowing instances to be shared across contexts to mitigate the object overhead drawback of the pattern.

Observer Pattern

A behavioral design pattern that defines a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.

Subject (Observer Pattern)

The core entity that tracks an arbitrary number of observing dependents and provides an interface to attach, detach, and notify observers when a state transition occurs.

Observer (Participant)

The interface or abstract class defining an updating protocol (typically update()) used by subjects to notify dependent objects of changes.

ConcreteSubject

A class that stores state of interest to ConcreteObservers and sends change notifications to its registered observers whenever its state is updated.

ConcreteObserver

A class that maintains a reference to a ConcreteSubject, stores synchronized state, and implements the update() method to query or reconcile with the subject's new state.

Abstract Coupling (Observer Benefit)

A benefit of the Observer pattern wherein a subject only knows its observers through an abstract interface, minimizing dependencies and permitting them to operate across distinct architectural layers.

Broadcast Communication (Observer Benefit)

A capability of the Observer pattern in which notifications are dispatched automatically to all subscribed observers without the subject requiring knowledge of specific receivers.

Unexpected Updates (Observer Drawback)

A drawback of the Observer pattern where observers are blind to the existence of one another, potentially causing costly, unexpected cascading state updates across the system.

Lack of Context (Observer Drawback)

A drawback of the Observer pattern wherein standard update notifications inform observers that a change has occurred but fail to supply granular details explaining what specifically changed.