What do DRY, KISS, YAGNI, and separation of concerns mean, and how do you apply them when writing Java?

## What these principles are These four are **clean-code principles**: language-neutral heuristics for writing code that humans can read, change, and trust. They sit *below* SOLID and design patterns — they're everyday rules of thumb, not structural blueprints. **DRY — Don't Repeat Yourself.** Coined in *The Pragmatic Programmer*. 'Every piece of knowledge must have a single, unambiguous, authoritative representation in a system.' If the same business rule, calculation, or string appears in three places, a change must be made in three places — and you'll miss one. In Java you remove duplication by extracting a `private` method, a shared utility class, a `static final` constant, a base class, or by introducing a parameter. *Caveat:* DRY is about duplicated **knowledge**, not duplicated **text**. Two methods that look identical today but represent unrelated rules (e.g. 'tax rate' and 'discount rate' that happen both to be 0.1) should stay separate — merging them couples concepts that will diverge. **KISS — Keep It Simple, Stupid.** Prefer the simplest design that solves the problem. A plain `if`/loop often beats a reflection-driven, generics-heavy framework. Simplicity aids readability, debugging, and onboarding. In Java this means: don't reach for `Stream`/reflection/inheritance when a method call does; choose clear names; keep methods short and single-purpose. **YAGNI — You Aren't Gonna Need It.** From Extreme Programming. Don't implement something until you actually need it. Speculative generality — adding a configuration knob, a plugin interface, or a layer 'in case we need it later' — usually costs maintenance now and the predicted need never arrives (or arrives differently). In Java this is the antidote to premature interfaces and over-deep class hierarchies. **Separation of Concerns (SoC).** A 'concern' is a distinct aspect of the program: input parsing, business logic, persistence, presentation, logging. SoC says keep these in distinct modules so each can be understood and changed in isolation. In Java this manifests as **layered architecture** (controller → service → repository), single-responsibility classes (the class-level form of SRP), and package boundaries. Frameworks like Spring encourage it (controllers vs services vs repositories). ## How they interact (and tug against each other) These principles overlap and sometimes **conflict**, which is why design is judgement, not rule-following: - **DRY vs KISS/coupling:** aggressively de-duplicating can introduce a shared abstraction that couples two modules that should evolve independently. Sometimes a little duplication is cheaper than the wrong abstraction ('duplication is far cheaper than the wrong abstraction' — Sandi Metz). - **YAGNI vs OCP:** OCP encourages extension points, but YAGNI warns against building them speculatively. The resolution: refactor *toward* an abstraction when a second concrete case actually appears, not before. - **KISS vs patterns:** a design pattern adds structure; if the problem doesn't need it, the pattern is complexity, not clarity. ## Worked example If three controller methods each format a currency the same way, extract a `MoneyFormatter` (DRY + SoC). But if you find yourself adding a `MoneyFormatterFactory` with a `Strategy` interface 'in case we support other formats later', stop — that's a YAGNI/KISS violation until a second format is real. ## Why it matters These principles keep code **changeable**. Most software cost is maintenance, and these heuristics reduce the surface you must touch and reason about per change. But they're heuristics, not laws — apply them with judgement, and let the conflicts between them push you toward the *simplest design that isn't repetitive and matches today's needs*.