Question 1

What are design patterns, and do they still matter?

Accepted Answer

**Design patterns** are named, reusable solutions to recurring design problems — vocabulary for structures that experienced developers kept independently reinventing. The idea was popularised by the 1994 book *Design Patterns* by four authors collectively known as the **Gang of Four**.

**What a pattern actually is.** Not code you copy, and not a library. It is a **description of a problem, a solution shape, and the trade-offs**. The value is largely in the **name** — saying "this is an observer" communicates a structure in two words that would otherwise take a paragraph.

**The three traditional categories:**

**Creational** — how objects get made. Factory, builder, singleton.

**Structural** — how objects compose. Adapter, decorator, facade, proxy.

**Behavioural** — how objects interact. Observer, strategy, command, iterator, state.

**The ones that genuinely earn their place:** **strategy** (swap an algorithm), **adapter** (make an incompatible interface fit), **observer** (notify dependents of change — the basis of every event system), **facade** (a simple front over a complicated subsystem), and **iterator** — now so standard it is built into most languages' syntax.

**The honest criticisms:**

**Several patterns are workarounds for missing language features.** Strategy and command are largely unnecessary where functions are first-class values; the iterator pattern is now `for...of`. As languages absorbed these capabilities, the patterns became invisible rather than obsolete.

**Singleton is widely regarded as an anti-pattern** — global mutable state with a respectable name, and a persistent obstacle to testing.

**Pattern-driven design produces over-engineering.** Choosing patterns first and fitting the problem to them is a recognisable failure mode, and it produces the abstract-factory-of-factories code that gave the field a bad reputation.

**The reasonable modern position:** learn them as **vocabulary and as a catalogue of trade-offs**, recognise them when they emerge naturally, and do not reach for them preemptively. The underlying advice — program to interfaces, prefer composition over inheritance — has aged considerably better than the specific catalogue.

Question 2

What is a design document, and why write one?

Accepted Answer

A written proposal describing what you intend to build and why, circulated before the work starts. Its value is not the document — it is that writing forces you to confront decisions you would

Question 3

What is refactoring, and how is it different from rewriting?

Accepted Answer

Refactoring is changing the internal structure of code without changing its external behaviour. That definition, from Martin Fowler, is precise and the constraint is what makes it refactoring rather

Question 4

What is infrastructure as code?

Accepted Answer

Defining servers, networks, databases and everything else supporting an application in files that are version-controlled and executed, rather than configuring them by hand through a console or by

Question 5

What makes a good API design?

Accepted Answer

Predictability above cleverness — a good API is one where a developer can guess correctly what something is called and how it behaves, because they will guess far more often than they will read the

Question 6

What is the difference between a library and a framework?

Accepted Answer

The distinction is about who calls whom, and it is usually summarised as inversion of control. With a library, you are in control. You write the application, and you call the library when you want

Question 7

Why does documentation always go out of date?

Accepted Answer

Because documentation and the code it describes are coupled in meaning but decoupled in enforcement — nothing breaks when they diverge, so they diverge. The core mechanism. Code has a merciless

Related Questions