Design Principles

DIP says important policy code must not depend on low-level detail code; both depend on an abstraction (an interface). What gets inverted is the source-code dependency: the detail now points at the abstraction instead of the policy pointing at the detail.

ISP — the "I" in SOLID — says no caller should be forced to depend on operations it never uses. Instead of one large interface with many unrelated methods, define several small ones, each matching what a particular caller actually needs.

If type S is a subtype of type T, code written against T must keep working correctly when handed an S. A subtype must honour the promises its supertype made — not just match method names.

You should be able to add new behavior to a module by adding new code (a new class or plug-in), without editing and re-testing the existing, already-working code.

SRP says a class or module should do one job, so only one kind of change forces you to edit it. If both a reporting change and a tax-rule change hit the same class, it has two responsibilities.

Cohesion is how strongly the things inside one module belong together. Coupling is how much one module depends on another. The rule: aim for high cohesion inside modules and low coupling between them.

Inheritance reuses code by making a new type a subtype of an existing one ("is-a"). Composition reuses code by holding another object as a field and calling it ("has-a"). Prefer composition: it couples types less and can change at runtime.

Abstraction hides detail behind a simpler idea you can reason about, like 'send a payment'. Indirection just means going through something in between instead of calling the thing directly. Abstractions use indirection, but a pass-through wrapper that hides nothing is only indirection.

CQS says every method should either change state (a command, returning nothing) or return information (a query, changing nothing) — never both. Put differently: asking a question must not change the answer.

Fail fast means checking for invalid input or state right where it appears and stopping immediately with a clear error, instead of continuing with bad data that causes a confusing failure much later somewhere else.

ADP says: allow no cycles in the dependency graph between components (releasable units like packages, modules, or libraries). Cycles cause the "morning-after syndrome": someone edits code you depend on overnight, your work breaks, and because dependencies loop, nobody can ever stabilize.

CCP says: put into one component the classes that change for the same reasons and at the same times. Then a typical change touches one component instead of many, so you rebuild, retest and redeploy less.

CRP says classes that are used together should be packaged together, and classes that are not used together should not be. It keeps consumers from depending on, rebuilding, and redeploying code they never use.

Instability I = outgoing dependencies / (outgoing + incoming). It says how easily a component can be forced to change. Abstractness A = abstract types / all types. It says how much of the component is interfaces rather than concrete code. Both run 0 to 1.

REP says the granule of reuse is the granule of release: the unit you reuse must be the unit you release. A component has to be published as a versioned whole, with a version number and release notes, so consumers depend on a specific version instead of copying files.

GRASP Controller says: don't let the UI widget itself do the work. Give the event to a separate non-UI object — a controller — that coordinates the domain objects and returns a result. This keeps screen code and business rules apart.

Creator says: give the job of making a new object to a class that already aggregates, contains, records, closely uses, or holds the data needed to build it. That class already knows about it, so creating it adds no new coupling.

Cohesion is how well everything inside one class belongs together. High Cohesion says a class should keep a small set of closely related responsibilities, so it stays easy to name, understand, change, test and reuse.

Indirection says: when two components would otherwise be wired directly together, put a third object between them to mediate. Neither side knows the other, so each can change or be replaced independently.

Give a job to the object that already holds the data needed to do it. If an order knows its line items, the order should compute its own total, instead of another class pulling the items out first.