Design Patterns interview questions and answers

Question 1

What is a design pattern?

Accepted Answer

A design pattern is a named, reusable solution to a problem that keeps coming up in software design. It is not code you copy, it is a recipe: 'here is the kind of problem, here is the shape of the fix'. The idea comes from the architect Christopher Alexander and was brought to software by the 'Gang of Four' book in 1994. Three things a pattern gives you: 1. A proven solution, other people already hit this wall and this is what worked. 2. A shared vocabulary, saying 'use an Observer here' tells a teammate the whole structure in two words. 3. More modular, maintainable code, patterns push you toward loose coupling. Analogy: cooking recipes. 'Make a roux' is a pattern: a known problem (thicken a sauce) and the core of the solution (equal fat and flour, cook, add liquid). Every cook adapts it, but naming it saves a paragraph of explanation. In an interview: I describe a pattern as a reusable design idea with a name, a problem/solution pair distilled from experience. The value is not the code, it is the shared vocabulary and the fact that the trade-offs are already understood.

Question 2

Why use design patterns? What are the benefits?

Accepted Answer

Reusability: you get a template instead of reinventing the wheel each project. Maintainability: standard structures are easier to read, debug and extend. Consistency: a team using the same patterns writes code that looks and behaves predictably. Faster problem-solving: recognising 'this is a classic X problem' points straight at a known fix. Communication: patterns are a common language, 'this is a Facade' replaces a long explanation. Avoiding pitfalls: many patterns exist precisely because a naive approach fails in a known way. Analogy: chess openings. A club player who knows named openings can discuss a whole sequence of moves in one word, skips the mistakes beginners make, and spends their thinking time on the parts that are actually novel. In an interview: The benefit I lead with is communication. Once a team shares the vocabulary, design discussions get much faster, and the code is more consistent because everyone reaches for the same well-understood structures.

Question 3

What are the three categories of design patterns?

Accepted Answer

The Gang of Four split 23 patterns into three groups by what they are about: Creational, how objects get created. They hide the 'new' and let you vary what is built, who builds it, and how. Examples: Singleton, Factory Method, Abstract Factory, Builder, Prototype. Structural, how objects and classes are composed into bigger structures. They make parts fit together and let structure change without breaking clients. Examples: Adapter, Bridge, Composite, Decorator, Facade, Proxy. Behavioral, how objects communicate and divide responsibility. They define who talks to whom and how work flows. Examples: Observer, Strategy, Command, Iterator, State, Template Method. Analogy: building a house. Creational = how the bricks and beams are manufactured and delivered. Structural = how the rooms and walls fit together. Behavioral = how the plumbing, wiring and people move through the finished house. In an interview: Creational is about making objects, structural is about assembling them, behavioral is about how they interact. When I hit a design problem I first ask which of the three buckets it falls into, that narrows the candidate patterns fast.

Question 4

How are design patterns different from principles, algorithms, and frameworks?

Accepted Answer

A principle (like SOLID, DRY) is a general guideline, 'depend on abstractions'. A pattern is a concrete structure that often puts a principle into practice. An algorithm is a precise step-by-step procedure to compute a result (quicksort), a pattern is a design blueprint, not a computation, and it is deliberately loosely specified. A framework is actual code you build on and that calls your code; a pattern is just an idea you implement yourself, language-agnostic. Analogy: principle = 'eat healthily'. Pattern = 'the Mediterranean approach to a meal'. Algorithm = 'the exact recipe with grams and minutes'. Framework = 'a meal-kit company that ships you the box and tells you when to cook'. In an interview: Principles are the 'why', patterns are a reusable 'how', algorithms are exact procedures, frameworks are code you extend. Patterns sit in the middle, more concrete than a principle, more flexible than an algorithm.

Question 5

What are the downsides of design patterns, and when should you not use one?

Accepted Answer

Over-engineering: adding a pattern where a plain class would do makes the code bigger and harder to follow. Added complexity: patterns often introduce extra classes, interfaces and indirection. Learning curve: someone new has to recognise the pattern to read the code. Misuse from familiarity: people apply the pattern they know rather than the one that fits. Not one-size-fits-all: each pattern targets a specific situation; forced outside it, it hurts. Rule of thumb: reach for a pattern when the problem it solves is actually present or clearly coming, not speculatively. If you cannot name the change or duplication it protects against, wait. Analogy: power tools. A nail gun is great when you are framing a house and terrible for hanging one picture. The tool is not the goal; the finished, maintainable thing is. In an interview: I treat patterns as a response to real pressure in the code, duplication, a hard-to-test seam, a class changing for many reasons. Applied speculatively they are just complexity. The goal is maintainable code, not a high pattern count.

Question 6

What problem do creational patterns solve?

Accepted Answer

They take control of object creation. Instead of scattering 'new ConcreteThing()' all over your code, which hard-wires every caller to a specific class, creational patterns put the creation logic in one place and hand callers an abstraction. That gives you three freedoms: vary WHAT is created (swap implementations), WHO creates it (a factory, a builder), and HOW it is created (step by step, cloned, pooled, cached). Analogy: ordering food instead of farming it. You say 'a burger'; the kitchen decides which grill, which cook, which steps. If they change suppliers you never notice, because you only ever touched the menu. In an interview: Creational patterns exist to stop 'new' leaking everywhere. Centralise creation, return an interface, and you can change the concrete type, the construction steps, or the lifecycle without touching call sites.

Question 7

Explain the Singleton pattern, and its problems.

Accepted Answer

Singleton makes sure a class has exactly one instance and gives everyone a single global way to reach it. You do it by making the constructor private (nobody can 'new' it) and exposing a static getInstance(). In the code: the constructor is private, so the only instance is the static field the class creates itself; getInstance() just returns it. This version is eager (created at class load) and therefore thread-safe for free. A lazy version (create on first call) needs synchronization or the 'holder' idiom to stay thread-safe. Problems: it is global mutable state, so it hides dependencies (a class using Singleton.getInstance() does not declare that need), makes unit testing hard (you cannot swap it for a fake), and can cause trouble across class loaders or in distributed systems. Many teams prefer a single instance managed by a DI container instead. Analogy: the government of a country. There is exactly one at a time, everyone can refer to 'the government', and you cannot just create your own. Convenient, but if everything secretly depends on it, nothing can be tested in isolation. In an interview: Singleton = private constructor plus a static accessor returning the one instance. I would immediately add the caveat: it is global state, it hides dependencies and hurts testability, so in an app with dependency injection I get 'one instance' from the container scope instead.

Question 8

Explain the Factory Method pattern.

Accepted Answer

Factory Method defines a method whose job is to create an object, but lets subclasses decide which concrete class to make. The base class writes its logic in terms of the product interface and calls the factory method; each subclass overrides that one method. In the code: Creator has abstract Product factoryMethod() and a real someOperation() that uses whatever the factory method returns. ConcreteCreatorA returns a ConcreteProductA, ConcreteCreatorB returns a ConcreteProductB. someOperation() never changes, only the creation point varies by subclass. Use it when a class cannot know ahead of time which object it needs, and you want to push that choice to a subclass or configuration. Analogy: a franchise recipe. Head office writes 'make the daily special and plate it' (someOperation). Each branch decides what the daily special actually is (factoryMethod). The plating steps are identical everywhere. In an interview: Factory Method is 'defer instantiation to a subclass'. The base class owns the workflow and calls an overridable creator method, so adding a new product type is a new subclass, not an edit to the workflow, that is OCP in action.

Question 9

What is the Abstract Factory pattern, and how is it different from Factory Method?

Accepted Answer

Abstract Factory gives you an interface for creating a whole family of related objects without naming their concrete classes. One factory object has several create methods, and each concrete factory produces a matching set. In the code: GuiFactory can create a Button and a Checkbox. WindowsFactory makes Windows-styled ones; MacFactory makes Mac-styled ones. The app picks a factory once at startup and every widget it builds is guaranteed to match. Difference: Factory Method is one method making one product, varied by subclassing. Abstract Factory is an object with several methods making a coordinated family of products, varied by swapping the whole factory. Abstract Factory is often built out of several Factory Methods. Analogy: a furniture company with a 'Victorian' line and a 'Modern' line. The Victorian factory makes a Victorian chair AND a matching Victorian table AND sofa. You choose the line once; everything that arrives goes together. In an interview: Factory Method = one product, chosen by subclass. Abstract Factory = a family of products that must stay consistent, chosen by swapping the factory. The classic example is cross-platform UI toolkits.

Question 10

Explain the Builder pattern.

Accepted Answer

Builder separates constructing a complex object from its final representation, so the same steps can build different results and you avoid giant constructors. You call small, readable methods to set each part, then build(). In the code: instead of new Pizza(12, true, false, true, 2, ...) where nobody can tell what the arguments mean, you write Pizza.builder().size(12).cheese().pepperoni().build(). The builder holds the half-built state and validates in build(). Use it when an object has many optional fields, when you want the object immutable once built, or when construction needs several ordered steps. Analogy: ordering a sandwich at a counter: 'white bread, no butter, chicken, add tomato, no onion'. Each choice is a clear step. You get the finished sandwich at the end, not a constructor with ten positional toppings. In an interview: Builder trades one unreadable constructor for a chain of named steps and a build() that validates. I use it for objects with lots of optional parameters or where I want immutability, each method returns 'this' so the calls read like a sentence.

Question 11

What is the Prototype pattern?

Accepted Answer

Prototype creates new objects by copying an existing one (the prototype) instead of building from scratch. The object knows how to clone itself. In the code: Shape has a clone() method. You configure one Circle exactly how you want it, then call clone() to get more just like it. Useful when construction is expensive (lots of setup, a database hit) or when you do not know the concrete class at compile time but you do have an instance to copy. The catch is deep vs shallow copy: a naive clone copies references, so the copy and original share nested objects. For independent copies you must deep-copy the mutable parts. Analogy: photocopying a filled-in form instead of writing every field again. Fast, but if the form points to a shared attachment, both copies point to the same attachment until you replace it. In an interview: Prototype is 'new object by copying an existing one'. It pays off when creating from zero is costly. The thing to watch is copy depth, share-by-reference bugs are the usual mistake, so I deep-copy anything mutable.

Question 12

What do structural patterns do?

Accepted Answer

They describe how to assemble classes and objects into larger structures while keeping the parts loosely coupled. The goals: let components with different interfaces work together (Adapter), let a structure grow without rewrites (Composite), let one part change without disturbing others (Bridge, Decorator), and give a simple front door to a complicated subsystem (Facade). Analogy: building with Lego. Each brick stands alone, but they clip together into something big and sturdy. Structural patterns are the different ways bricks connect, and adapters for when two bricks do not fit directly. In an interview: Structural patterns are about composition, fitting objects together. Each one solves a specific fit problem: incompatible interfaces, adding behaviour, hiding complexity, tree structures, controlled access.

Question 13

Explain the Adapter pattern.

Accepted Answer

Adapter converts the interface of one class into the interface a client expects, so two things that were not built to work together can. You wrap the incompatible object and expose the methods the client wants, translating calls internally. In the code: the OldSystem returns XML. The NewSystem needs JSON. Rather than editing either one, the Adapter holds an OldSystem, calls its XML method, converts XML to JSON, and exposes getEmployeeDataInJSON(). The client talks only to the adapter. Analogy: a travel power adapter. Your laptop plug and the foreign socket are both fine, they just do not fit. The adapter sits between them and translates the shape. Neither the laptop nor the wall is modified. In an interview: Adapter is a translator between interfaces. It lets you reuse existing or third-party code that does not match your expected interface, without modifying it, you wrap it and adapt the calls.

Question 14

Explain the Decorator pattern.

Accepted Answer

Decorator adds responsibilities to a single object at runtime by wrapping it in another object that has the same interface. Each decorator does its bit, then delegates to the thing it wraps. You can stack them in any order. In the code: Coffee has cost(). Milk and Sugar are decorators that also implement Coffee, hold an inner Coffee, and add to its cost. new Sugar(new Milk(new SimpleCoffee())) is a coffee with milk and sugar, and callers still just see Coffee. It is the flexible alternative to subclassing for every combination (MilkCoffee, SugarCoffee, MilkSugarCoffee...). Analogy: getting dressed. A scarf, then a coat, then a raincoat, each layer wraps the last, each adds warmth or waterproofing, and you are still 'a person' underneath. You add or remove layers as needed. In an interview: Decorator = wrap an object in another with the same interface to add behaviour, stackable at runtime. It beats a class explosion of every feature combination, and it is exactly how java.io streams work (BufferedInputStream wrapping FileInputStream).

Question 15

Explain the Facade pattern.

Accepted Answer

Facade puts one simple interface in front of a complicated subsystem. The subsystem still exists and can be used directly by anyone who needs the detail, but most callers just use the facade, which coordinates the messy steps for them. In the code: starting a computer really means CPU.freeze(), memory.load(...), cpu.jump(...), cpu.execute(). ComputerFacade.start() bundles that into one call. The client says computer.start() and knows nothing about CPU or Memory. Analogy: a hotel concierge. Booking a restaurant, a taxi and theatre tickets involves three companies. You ask the concierge once; they deal with all three. The restaurants still take direct bookings, the concierge is a convenience, not a wall. In an interview: Facade is a friendly front door to a subsystem. It reduces coupling, callers depend on the facade, not on a dozen internal classes, without hiding the subsystem from those who genuinely need it.

Question 16

Explain the Composite pattern.

Accepted Answer

Composite lets you treat a single object and a group of objects the same way, by having both implement one interface. A 'leaf' does the real work; a 'composite' holds children (leaves or other composites) and forwards the call to each. Client code recurses through a tree without ever checking 'is this one item or many?'. In the code: FileSystemNode has size(). A File returns its own size. A Folder returns the sum of its children's size(). A folder of folders of files just works, because size() is the same call at every level. Analogy: a company org chart. 'Total headcount under this person' works whether you point at an individual contributor (1) or a VP with hundreds below them, you ask the same question and it rolls up the tree. In an interview: Composite = uniform treatment of individual objects and compositions via a shared interface. It is the pattern behind file systems, UI component trees and DOM nodes, anywhere you have part-whole hierarchies.

Question 17

Explain the Proxy pattern.

Accepted Answer

A Proxy is a stand-in that implements the same interface as a real object and controls access to it. Clients think they are talking to the real thing. The proxy can add: lazy creation (build the real object only on first use), access control (check permissions), caching, logging, or remote calls. In the code: Image has display(). RealImage loads a big file in its constructor. ProxyImage implements Image but does not create the RealImage until display() is actually called, so listing 100 images is cheap; only the ones shown pay the load cost. Analogy: a personal assistant. You send requests to the assistant (proxy); they decide whether to bother the executive (real object), keep a log, or answer from memory if they already know. Same 'interface' to you. In an interview: Proxy = same interface as the real object, but it intercepts calls to add lazy loading, security, caching, or remoting. Spring's AOP and lazy beans are proxies; so is a Hibernate lazy entity.

Question 18

Explain the Bridge pattern.

Accepted Answer

Bridge splits a thing into two separate hierarchies, an abstraction and an implementation, connected by a reference (the 'bridge'), so each can be extended without touching the other. It prevents a class explosion when you have two independent dimensions of change. In the code: shapes (Circle, Square) is one dimension; drawing APIs (vector, raster) is another. Without Bridge you would need VectorCircle, RasterCircle, VectorSquare, RasterSquare... With Bridge, Shape holds a DrawingApi. Add a shape: one class. Add a rendering API: one class. Combinations are free. Analogy: TV remotes and TVs. Remotes vary (basic, universal, voice). TVs vary (Sony, Samsung, LG). You do not build a class for every remote-TV pair, the remote holds a reference to 'a TV' and calls its buttons. In an interview: Bridge decouples an abstraction from its implementation so the two vary independently. The tell is 'I have two dimensions of variation and I am getting a combinatorial number of subclasses', Bridge turns multiplication into addition.

Question 19

How do Adapter, Decorator, Proxy and Facade differ? They all wrap something.

Accepted Answer

All four wrap an object, but the intent differs: Adapter, changes the interface. Input interface A, output interface B, so an incompatible client can use it. Decorator, keeps the interface, adds behaviour. Same interface in and out, but does more. Meant to be stacked. Proxy, keeps the interface, controls access. Same interface, same behaviour, but gates it: lazy, secure, cached, remote. Facade, introduces a new, simpler interface over many objects. Wraps a whole subsystem, not one object, and does not implement the subsystem's interfaces. Analogy: Adapter = translator. Decorator = adding toppings. Proxy = a gatekeeper who looks identical to the person behind the door. Facade = a receptionist for a whole building. In an interview: Same structure, different purpose: Adapter converts an interface, Decorator adds behaviour behind the same interface, Proxy controls access behind the same interface, Facade invents a simpler interface over a subsystem.

Question 20

What do behavioral patterns do?

Accepted Answer

They organise how objects communicate and how responsibility is shared, so the interactions stay flexible and loosely coupled. Instead of objects calling each other directly and rigidly, behavioral patterns introduce clear channels: publish/subscribe (Observer), pluggable algorithms (Strategy), requests as objects (Command), step-by-step traversal (Iterator), behaviour that depends on internal state (State). Analogy: office processes. Not 'who is in the building' but 'how a request moves through it', who you email, who signs off, what happens when a form is submitted. Behavioral patterns are the workflow rules. In an interview: Behavioral patterns are about interaction and responsibility, how work and messages flow between objects, with the constant aim of keeping the collaborators loosely coupled.

Question 21

Explain the Observer pattern.

Accepted Answer

Observer sets up a one-to-many link: one subject holds a list of observers and, whenever its state changes, calls a method on each of them. Observers register and unregister at runtime and do not know about each other. The subject knows only 'something implementing Observer', not the concrete types. In the code: WeatherStation keeps a list of WeatherObserver. setMeasurements() updates the data and calls notifyObservers(), which loops and calls update() on each. CurrentConditionsDisplay and ForecastDisplay each react in their own way. Add a new display: implement the interface and register, the station code does not change. Analogy: a newsletter. The publisher keeps a subscriber list. When a new issue is ready, everyone on the list gets it. Subscribers come and go; the publisher never checks who is reading, it just sends. In an interview: Observer = publish/subscribe between objects. The subject broadcasts state changes; observers react. It keeps them loosely coupled and lets you add reactions without touching the subject. It underlies event listeners, UI data binding and messaging.

Question 22

Explain the Strategy pattern.

Accepted Answer

Strategy defines a family of interchangeable algorithms behind one interface and lets the caller pick which one to use, at runtime. The context object holds a strategy reference and delegates the varying work to it. In the code: ShippingCost is the strategy interface. Standard, Express and International are implementations. Order holds a ShippingCost and calls it in total(). Switching shipping method is one setter call, no if/else chain, and a new method is a new class. Analogy: travel modes in a maps app. 'Get me there' is fixed; 'by car / bike / transit / walking' are swappable strategies. You choose one and the route logic changes, but the app around it does not. In an interview: Strategy = pull an algorithm out into its own object so it can be swapped. It replaces conditionals-on-a-type with polymorphism, and it is the go-to way to satisfy Open/Closed for 'the rules keep changing' problems.

Question 23

Explain the Command pattern.

Accepted Answer

Command turns a request into a standalone object that carries everything needed to perform it later, the receiver, the method, the arguments. Because the request is now an object you can queue it, log it, schedule it, or keep a history for undo/redo. In the code: Command has execute() and undo(). LightOnCommand holds a Light and calls on()/off(). A RemoteControl stores commands and a history stack; pressing a button runs a command and pushes it; undo pops and calls undo(). The remote knows nothing about lights. Analogy: a restaurant order ticket. The waiter writes the request on a ticket (command object) and puts it on the rail. The kitchen (receiver) executes it. Tickets can be queued, re-fired, or voided, because the request is a physical thing, not a shout. In an interview: Command = a request wrapped as an object, which gives you undo/redo, queuing, logging and scheduling. GUI actions, job queues and transaction logs are all Command.

Question 24

Explain the Template Method pattern.

Accepted Answer

Template Method puts the fixed skeleton of an algorithm in a base class method, and leaves specific steps as abstract (or overridable) methods that subclasses fill in. The overall order is locked; only the marked steps vary. This is the 'Hollywood principle', don't call us, we'll call you. In the code: DataExporter.export() runs fetch(), then format(), then save(), always in that order. CsvExporter and JsonExporter only implement format(). You cannot accidentally reorder the steps, and shared steps live in one place. Analogy: a recipe template for a cake: preheat, mix dry, mix wet, combine, bake, cool. The steps and order are fixed; 'mix dry' differs between a chocolate cake and a lemon cake. You override the flavour steps, not the structure. In an interview: Template Method = fixed algorithm skeleton in the base class, variable steps in subclasses. It removes duplication when several flows are 'the same except for a step or two', and it keeps control of the sequence in one place. Strategy does a similar job with composition instead of inheritance.

Question 25

Explain the Iterator pattern.

Accepted Answer

Iterator gives you a standard way to walk through the elements of a collection one at a time without exposing how the collection stores them. The collection produces an iterator object with hasNext() and next(); client code loops on those and never touches the internal array, list or tree. In the code: Java's own Iterable/Iterator is this pattern. A custom Playlist exposes iterator() so a for-each loop works, whether songs are held in an array, a linked list, or shuffled order, the loop does not change. Analogy: a TV remote's channel-up button. You step through channels one at a time. You do not need to know if channels are stored as a list, a frequency table, or a database, 'next' just works. In an interview: Iterator = uniform traversal that hides the collection's structure. In Java it is baked into the language via Iterable and the for-each loop, which is why you rarely write it by hand but use it constantly.

Question 26

Explain the State pattern.

Accepted Answer

State lets an object change its behaviour when its internal state changes, it looks like the object changed class. Each state is its own object implementing a common interface; the context delegates to the current state object and lets it decide what happens next, including which state to move to. In the code: a vending machine behaves differently to 'insert coin' and 'dispense' depending on whether it is idle, has money, or is sold out. Instead of a giant switch in every method, each state class handles the events its own way and sets the machine's next state. Analogy: a traffic light. 'Time tick' does something different depending on whether it is currently red, amber or green, and each colour knows which colour comes next. The light is one object that acts like three. In an interview: State = one object per state, each handling events and deciding the next state, with the context delegating to the current one. It replaces sprawling if/switch-on-status code and makes the state machine explicit.

Question 27

Strategy and State look identical, what is the difference?

Accepted Answer

Structurally they are the same: a context delegates to a swappable object behind an interface. The difference is intent and who swaps it. Strategy: the client chooses the algorithm and it usually stays put for the life of the operation. The strategies do not know about each other. Purpose: vary how one job is done. State: the objects swap themselves. A state transition happens inside a state method, based on events. States know about the other states they can move to. Purpose: model a lifecycle where behaviour depends on status. Analogy: Strategy is picking your route mode before a trip (car vs transit). State is a chess game moving from opening to midgame to endgame, the game changes its own phase as moves happen, and each phase leads to specific next phases. In an interview: Same shape, different story. Strategy is 'the caller picks an interchangeable algorithm'. State is 'the object walks itself through a lifecycle, and each state knows its successors'.

Question 28

Where do design patterns show up in the JDK and common frameworks?

Accepted Answer

They are everywhere once you look: Singleton, Runtime.getRuntime(); Spring beans are singleton-scoped by default. Factory Method, Calendar.getInstance(), List.of(). Builder, StringBuilder, Stream.Builder, HttpRequest.newBuilder(). Decorator, java.io (BufferedReader wrapping FileReader), Collections.unmodifiableList(). Adapter, Arrays.asList(), InputStreamReader (bytes to chars). Observer, java.util.concurrent Flow API, Swing/Android listeners, Spring ApplicationEvent. Strategy, Comparator passed to sort(), Spring's many *Strategy interfaces. Template Method, AbstractList, Spring's JdbcTemplate, servlet's service()/doGet(). Proxy, Spring AOP, Hibernate lazy loading, java.lang.reflect.Proxy. Iterator, every Collection. Analogy: learning the names of common wildflowers. Suddenly a walk you have taken a hundred times is full of things you can identify and talk about. In an interview: I would rattle off a few concrete ones, java.io as Decorator, Comparator as Strategy, JdbcTemplate as Template Method, Spring AOP as Proxy, because it shows the patterns are not academic, they are the design language of the libraries we use daily.

Question 29

How do you decide which pattern to use?

Accepted Answer

Start from the problem, not the catalogue. First classify it: is this about creating objects, composing them, or how they interact and behave? That picks the category. Then match the specific pain: 'incompatible interface' -> Adapter; 'too many constructor args' -> Builder; 'behaviour must be chosen at runtime' -> Strategy; 'many things must react to a change' -> Observer; 'need undo' -> Command; 'behaviour depends on status' -> State. If nothing fits cleanly, do not force one, a plain class is a valid answer. Analogy: diagnosis before prescription. A doctor identifies the category of complaint first (respiratory? digestive?), then narrows to the specific condition, then treats. Reaching for your favourite medicine first is how you get it wrong. In an interview: Category first, creational, structural or behavioral, then match the exact symptom to a pattern. And I keep 'no pattern' on the table; the smallest thing that solves the problem wins.

Question 30

What does misuse of design patterns look like?

Accepted Answer

Pattern-itis: every class is a Factory, a Manager, a Strategy, and you cannot find where the actual work happens. Singleton overuse: turning half the app into global state that cannot be tested. Speculative generality: a Bridge or Abstract Factory 'in case we support another provider' that never comes. Wrong pattern from familiarity: using Observer for a simple direct call because you like events. Cargo-culting: copying a pattern's structure without its intent, so you get the boilerplate and none of the benefit. Analogy: someone who just bought a label maker. Suddenly every drawer, shelf and cable has three labels. The labels stopped helping around label number two. In an interview: The main failure mode is adding a pattern's machinery when the problem it addresses is not present. I ask 'what specifically gets easier because of this?', if I cannot answer concretely, the pattern comes out.

Question 31

How do design patterns relate to the SOLID principles?

Accepted Answer

Patterns are largely SOLID made concrete. Strategy, Factory Method and Abstract Factory are ways to get Open/Closed and Dependency Inversion, depend on an interface, add behaviour as new implementations. Decorator and Composite lean on Liskov Substitution, since wrappers and children must be usable wherever the base type is. Facade and Adapter reduce coupling, supporting the spirit of Interface Segregation and Dependency Inversion. Observer and Command decouple sender from receiver. If you apply SOLID well, you often rediscover these patterns on your own. Analogy: SOLID is the grammar; patterns are common, well-formed sentences in that grammar. You could build the sentence yourself from the rules, but it is faster to recognise and reuse the good ones. In an interview: Most Gang of Four patterns are a recipe for satisfying one or two SOLID principles, usually Open/Closed and Dependency Inversion via an interface plus interchangeable implementations. Patterns give the recipe a name and pre-worked trade-offs.

Design patterns interview preparation

What design patterns are

Creational patterns

Structural patterns

Behavioral patterns

Patterns in practice