Stufe 5·Software-Handwerk

General Engineering Principles

DRY, KISS, YAGNI, Separation of Concerns, Least Astonishment, Law of Demeter, and more.

16 Min. LesezeitFortgeschritten

Deutsche Übersetzung in Arbeit

Diese Lektion ist noch nicht ins Deutsche übersetzt und wird daher auf Englisch angezeigt. Der Rest der Seite ist vollständig lokalisiert.

Auf dieser Seite

Beyond SOLID lies a set of timeless, memorable principles that guide good software engineering. They're short, sharp, and pay off every single day. Learn the acronyms - you'll hear them throughout your career.

DRY - Don't Repeat Yourself

Every piece of knowledge should live in one place. Duplicated logic means duplicated bugs - fix it in one spot and the copies still break.

// WET ("Write Everything Twice") - the same rule copied around
if (user.age() >= 18) { /* ... */ }        // here
if (customer.age() >= 18) { /* ... */ }    // and here

// DRY - one source of truth
boolean isAdult(Person p) { return p.age() >= 18; }

DRY is about knowledge, not text

Don't blindly merge code that merely looks similar. Two rules that happen to be identical today but change for different reasons should stay separate. DRY is about single sources of knowledge, not eliminating every similar-looking line.

KISS - Keep It Simple, Stupid

Prefer the simplest solution that works. Clever, complex code is harder to read, test, and maintain.

Simple is a feature

A door that just opens beats a door with a fingerprint scanner, an app, and a backup laser - more parts, more to break, more to explain. In code, reach for the plainest approach that solves the actual problem. Complexity should have to earn its place.

YAGNI - You Aren't Gonna Need It

Don't build features or flexibility you only might need someday. Build for today's real requirements.

// YAGNI violation: elaborate config for a single, fixed use case
class Report {
    // 12 configuration options, plugin system, 3 export formats...
    // ...but the app only ever prints one plain report.
}

Speculative generality costs you now

Every 'just in case' abstraction is code to write, test, and maintain for a need that may never arrive. Add flexibility when a real requirement demands it - not before. Simpler now beats hypothetically-convenient later.

Separation of Concerns (SoC)

Split a program into distinct sections, each handling one concern - like the classic layers: presentation (UI), business logic, and data access. Each can change independently.

SoC is like a well-run restaurant

The waiter (UI) takes orders, the chef (business logic) cooks, the supplier (data layer) provides ingredients. Each does their job without doing the others'. Change the menu without retraining the suppliers. Separating concerns keeps each part focused and swappable.

POLA - Principle of Least Astonishment

Code should behave the way its readers expect. Surprises are bugs waiting to happen.

// Astonishing: a "getter" that secretly changes state
int getCount() {
    count++;               // WHAT? getting shouldn't mutate!
    return count;
}

A method named getX should just return X. Follow conventions so nobody is surprised.

Law of Demeter - "don't talk to strangers"

An object should only talk to its immediate friends, not reach deep through chains of other objects.

// Violation: reaching through a chain (fragile)
order.getCustomer().getAddress().getCity().toUpperCase();

// Better: ask the object directly
order.getCustomerCity();

Long chains couple you to the internal structure of everything in between - change any link and your code breaks.

Quick check

You're tempted to add a configurable plugin system for a feature nobody has asked for yet. Which principle says don't?

Key takeaways

DRY: keep each piece of knowledge in one place - but don't merge things that only look alike.
KISS: prefer the simplest solution that works; complexity must earn its place.
YAGNI: build for real, current requirements - not speculative future ones.
Separation of Concerns: divide the program into focused, independently-changeable parts.
POLA: make code behave the way readers expect; avoid surprising side effects.
Law of Demeter: talk to immediate collaborators, not through long object chains.

Next, we focus on object-oriented design principles - the guidelines for how classes relate to one another.