Spot the class that builds its own collaborators with new, move that construction up into a constructor parameter so the same class turns testable with a fake and swappable in production, and tell true injection apart from a service locator that only looks like it.

An `OrderConfirmation` class builds its own `new SmtpMailer()` in the constructor, so every test needs a live mail server and switching providers means editing the class itself. The trap is building what you could be handed.

Extract the shared skeleton of two near-identical methods into a parent that calls overridable steps by name, recognize the same fixed-order shape in framework lifecycle hooks like a test runner's setUp/tearDown, and tell it apart from the run-time version you inject instead of inherit.

Two `export()` methods sit in two classes: both open a file, write a header, write each row, and close. The only lines that differ are how a row gets formatted, yet you copied the whole skeleton.

Pull a loop's index out into a separate cursor that answers next and hasNext, read the same protocol across Python's StopIteration, JavaScript generators, Java's hasNext, and Rust's Option, and tell an iterable apart from the one-pass iterator it hands you.

A `for (i = 0; i < shelf.books.length; i++)` loop works until the day `books` stops being an array. Reach into the backing array and every loop you wrote breaks once that collection becomes a tree or a stream.

Weigh a pattern's up-front indirection against the flexibility it only repays when real variation arrives, name the three ways that bet goes wrong (an abstraction built too early, one bent with a flag per case, a favourite pattern swung at every problem), and wait for the rule of three before you abstract.

A three-line `switch` on payment type grew into an interface plus four classes across four files, though nothing varies yet that the `switch` couldn't hold. You paid the cost of flexibility the code never spends.