5 exercises — practise the English vocabulary engineers use when discussing GoF design patterns: creational pattern distinctions, observer vs. pub/sub, decorator wrapping, facade simplification, and the adapter vs. bridge distinction.
0 / 10 completed
1 / 10
Your tech lead describes the Factory Method pattern: "It lets subclasses decide which class to instantiate." A colleague asks which pattern goes further by providing "an abstract interface for creating families of related objects without specifying their concrete classes." Which pattern is your colleague describing?
Creational pattern vocabulary comparison:
The Abstract Factory is the correct answer. It extends Factory Method by grouping related factories behind a common interface, ensuring that the products from a single factory are compatible with each other.
Pattern
Creates
Key vocabulary
Example
Factory Method
One product via subclass override
"lets subclasses decide which class to instantiate"
LoggerFactory.create()
Abstract Factory
Families of related products
"interface for creating families… without specifying concrete classes"
UIFactory → Button + Checkbox (per OS theme)
Builder
One complex object step by step
"separates construction from representation"
QueryBuilder.select().where().limit()
Prototype
Copies of existing instances
"cloning", "copy constructor"
config.clone() with overrides
How to use this in an architecture discussion:"We're using an Abstract Factory so the UI layer can switch between the Material and Fluent design systems without touching the component consumers — the factory guarantees the products are always from the same family."
2 / 10
A tech lead says: "We used the observer pattern so our UI components subscribe to the data model and update automatically when state changes." In a system design review, how would you correctly describe the key vocabulary difference between the observer pattern and the pub/sub messaging pattern?
Observer vs. pub/sub vocabulary distinction:
The key architectural difference is coupling and synchrony, not just naming.
Dimension
Observer pattern
Pub/Sub pattern
Coupling
Subject holds references to observers — tight coupling
Publisher and subscriber know only the broker — fully decoupled
Synchrony
Typically synchronous (observers called in-process)
Typically asynchronous (messages queued in broker)
Location
In-process, single application
Cross-process, distributed systems
Examples
DOM EventTarget, Redux store subscriptions, React Context
Kafka topics, RabbitMQ exchanges, SNS/SQS
Architecture discussion phrases:
"The observer pattern gives us synchronous state propagation within the process, but if we need cross-service notifications we'd move to a pub/sub broker."
"The trade-off of observer is that slow observers block the subject's notification loop — pub/sub avoids this by decoupling delivery."
3 / 10
A senior engineer describes your Express.js middleware pipeline: "Each middleware function wraps the next one, adding behaviour before and after — the request flows in, gets transformed, and flows out." Which design pattern term most precisely describes this structure?
Structural pattern vocabulary — Decorator vs. similar patterns:
The Decorator pattern best describes middleware wrapping. The defining characteristic is that each layer wraps the next and executes code both before and after delegating to the inner call — exactly the middleware model.
Pattern
Core mechanism
Distinguishing feature
Decorator
Wraps an object, delegates to it, adds behaviour around the call
Layered wrapping; before + after hooks; same interface as wrapped object
Strategy
Swaps a pluggable algorithm implementation
No wrapping; replaces not augments; single active strategy at a time
Chain of Responsibility
Linear chain; each handler decides to handle or pass
Handlers are independent; the chain stops when one handles the request
Proxy
Controls access to a specific object
Single wrapping layer; access control focus, not behaviour augmentation
Real-world examples to cite in discussions:
Python function decorators (@login_required, @cache) — Decorator pattern
Your tech lead describes a new service: "We created a single OrderService class that coordinates inventory, payment, and shipping. Callers don't need to know anything about the subsystems — they just call OrderService.placeOrder()." Which design pattern does this implement?
Structural pattern vocabulary — Facade:
The Facade pattern is exactly this: a layer that simplifies access to a complex subsystem by exposing a coherent high-level interface.
Pattern
Purpose
Relationship to subsystem
Facade
Simplifies a complex subsystem for external callers
Hides multiple subsystems behind one entry point
Mediator
Reduces coupling between peer objects that interact with each other
Objects coordinate through the mediator, which routes messages between them
Proxy
Controls access to one specific object
One-to-one substitution; same interface as the wrapped object
Adapter
Translates one interface into another expected by the client
Interface translation, not simplification
Facade vocabulary phrases for architecture discussions:
"The Order API is a facade over three bounded contexts — it keeps the client simple while the domain complexity lives behind the boundary."
"We deliberately kept the facade thin — business logic belongs in the subsystems, not in the coordination layer."
"The facade also acts as an anti-corruption layer between the external API contract and our internal domain model."
5 / 10
An architect says: "We need an adapter to make this third-party payment SDK fit our domain's PaymentGateway interface — the SDK's method signatures are completely different from what our code expects." In an architecture review, how would you correctly distinguish the Adapter pattern from the Bridge pattern?
Adapter vs. Bridge — structural pattern vocabulary:
These two patterns look similar in structure (both involve an intermediary class) but differ fundamentally in intent and timing.
Dimension
Adapter
Bridge
Intent
Make incompatible interfaces work together
Decouple abstraction from implementation so each can vary independently
Design timing
Retroactive — applied after the fact to patch an incompatibility
Upfront — designed intentionally before implementation to allow extensibility
When to use
Integrating third-party SDKs, legacy code, or external APIs into your domain model
Designing an abstraction that must support multiple implementations (e.g., multiple rendering backends)
"We're wrapping the Stripe SDK behind our PaymentGateway interface — that's a classic adapter; we own the interface, not the implementation."
"The notification system uses a Bridge so we can add new channel implementations (email, SMS, push) without modifying the notification abstraction layer."
6 / 10
During a code review of a new feature for an e-commerce platform, a developer comments: 'I've implemented the Strategy pattern here. This allows us to easily swap out payment processors without modifying the core order placement logic.' A reviewer asks, 'Can you elaborate on why this approach is beneficial and how it relates to maintaining flexibility?' Which of the following best captures the reviewer's intent regarding the Strategy pattern?
The reviewer isn't asking for a technical definition of the Strategy pattern. They're probing for *why* it was chosen—specifically, the benefit of loose coupling and adaptability. The incorrect options either miss this point or incorrectly frame the pattern's primary purpose as code organization rather than runtime flexibility.
7 / 10
You're in a Slack channel discussing architectural decisions with your team. A junior developer writes: 'I'm using the Decorator pattern to add new features to our user profile without creating separate classes for each one.' A senior engineer replies, 'That's interesting. Can you explain how this differs from simply extending existing classes?' Which of these responses best reflects a key distinction between the Decorator and Inheritance patterns in this context?
The core difference between Decorators and Inheritance lies in their impact on class hierarchies. Decorators provide dynamic extension without creating new classes, while inheritance creates rigid, often deep, class structures. The response directly addresses this crucial distinction.
8 / 10
You're working with a REST API that provides product data. The API returns a JSON payload like this: `{"product": {"id": 123, "name": "Widget", "price": 9.99, "options": ["Red", "Blue"]}}`. A colleague asks you to describe how the Factory pattern could be used to manage the creation of these product objects in your application. Which description best aligns with this scenario?
The key benefit of a Factory pattern is encapsulation—hiding the creation logic. In this case, it would manage the complexities of creating Product objects with varying options, simplifying the code and promoting maintainability.
9 / 10
You're writing a pull request description for a refactoring that introduced the Command pattern into your application's workflow. You want to clearly explain the benefits of this change to reviewers. Which of the following options best summarizes the core advantage of using the Command pattern in this scenario?
The fundamental advantage of the Command pattern is the ability to treat commands as objects. This enables features like undo/redo and decouples the sender (the client) from the receiver (the object performing the action), promoting flexibility and maintainability.
10 / 10
During a daily stand-up meeting, you're discussing your progress on a new feature. You say: 'I've used the Observer pattern to notify other services when a user updates their profile information.' A team member asks, 'How does that differ from just directly calling those services?' What is the most accurate way to explain the value of the Observer pattern in this context?
The core value of the Observer pattern is loose coupling and asynchronous communication. This prevents cascading updates (where one change triggers a chain reaction) and improves system resilience by reducing dependencies between components.
What will I learn from the "Design Patterns Vocabulary — Software Architecture Exercises" exercise?
Practice English for design pattern discussions: Abstract Factory vs. Factory Method, observer vs. pub/sub, Decorator middleware, Facade pattern, and Adapter vs. Bridge. 5 intermediate exercises.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall required.
How many questions are in this exercise?
This set contains 10 multiple-choice questions, each with a detailed explanation shown after you answer.
Do I need to create an account to track my progress?
No account is required. Your progress bar and score reset each time you reload the page, but you can retry the exercise as many times as you like.
Who is this Software Architecture exercise for?
This exercise is built for IT professionals and non-native English speakers who need to read, write, and discuss software architecture topics confidently at work.
What happens if I answer a question incorrectly?
You will see the correct answer highlighted along with a detailed explanation of why it is correct -- so every wrong answer becomes a learning moment, not just a lost point.
Can I retry this exercise?
Yes -- click "Try again" on the results screen at any time to reset your score and go through all the questions again.
How long does this exercise take to complete?
Most learners finish all 10 questions in under 10 minutes, since each question is answered by clicking a single option.
Where can I find more Software Architecture exercises?
See the full Software Architecture exercises hub for more vocabulary drills on this topic.
Is this exercise mobile-friendly?
Yes -- the exercise works on any device with a modern browser, including phones and tablets, with no app download required.