Design Concepts are fundamental ideas that explain and justify design decisions. They are the theoretical foundation that makes design principles make sense.
What Makes Something a Design Concept?
A design concept:
- Explains WHY: Provides the reasoning behind design decisions
- Is descriptive: Describes properties and relationships in systems
- Forms foundations: Underlies and justifies design principles
- Is measurable/observable: Can be evaluated in existing code
Examples of descriptive statements:
- “A class invariant defines the valid region of object states”
- “Cohesion measures how related responsibilities within a module are”
- “Coupling describes dependencies between modules”
Core Concepts
Class Design Foundations
Invariants
The mathematical foundation of object-oriented design. An invariant defines:
- What makes an object valid: The “valid region” of all possible states
- When classes are justified: A class should exist if and only if it has an invariant to maintain
- Why SOLID principles work: They’re not “wishy washy guidelines” but concrete rules derived from invariant maintenance
“Bjarne Stroustrup: My rule of thumb is that you should have a real class with an interface and a hidden representation if and only if you can consider an invariant for the class.”
Invariants explain:
- Why encapsulation matters (protect the invariant)
- Why methods belong on classes (maintain the invariant)
- Why SOLID principles are mathematical, not just aesthetic
Constraints over Conventions
Extends the invariant idea past the object boundary into the database. An invariant must hold on every write path; a convention (a lifecycle callback, a “remember to call X” agreement) only holds on the paths that opt in. Hard invariants belong in the data layer as constraints, where they have no bypass list.
Modularity Concepts
Coupling
The degree of interdependence between software modules.
- Low coupling: Modules can change independently
- High coupling: Changes ripple across modules
- Related principles: Law of Demeter
Cohesion
How strongly related and focused the responsibilities within a module are.
- High cohesion: Related functionality grouped together
- Low cohesion: Unrelated responsibilities mixed together
- Related principles: Single Responsibility Principle
See also: Tidyings - Cohesion Order technique
Package Principles
Six principles by Robert C. Martin governing package/component organization:
- Cohesion principles (what goes inside packages): REP, CRP, CCP
- Coupling principles (relationships between packages): ADP, SDP, SAP
- Related concepts: Coupling, Cohesion, SOLID
Object-Oriented Concepts
Encapsulation
Information hiding and bundling data with methods that operate on that data.
- Purpose: Protect invariants by controlling access to internal state
- Implementation: Private fields, public methods, interfaces
- Related principles: Tell, Don’t Ask
Globals and Ambient Context
Request/thread-scoped context (current user, tenant, request id) read without being passed as an argument.
- Purpose: Keep secondary, orthogonal cross-cutting metadata out of every method signature
- Risk: Becomes hidden coupling when smuggled into primary domain decisions
- Related concepts: Coupling, Inversion of Control
Polymorphism
The ability of different types to be treated uniformly through a common interface.
- Purpose: Enable extension and substitution
- Implementation: Inheritance, interfaces, generics
- Related principles: Closed, Liskov Substitution, Dependency Inversion
Abstraction
Simplifying complex reality by modeling classes appropriate to the problem.
- Purpose: Hide complexity, expose only what’s necessary
- Risk: Wrong abstractions are worse than duplication
- Related principles: DRY, YAGNI
Control Flow
Inversion of Control
Framework-controlled flow vs traditional control flow.
- Purpose: Decouple components by inverting control flow
- Implementation: Dependency injection, event-driven programming, template methods
- Related principles: Dependency Inversion Principle
How Concepts Inform Principles
Design concepts provide the theoretical foundation for principles:
| Concept | Informs Principle | Relationship |
|---|---|---|
| Invariants | SOLID principles | Classes exist to maintain invariants |
| Coupling | Law of Demeter | Minimize dependencies between objects |
| Cohesion | Single Responsibility | Group related functionality |
| Encapsulation | Tell, Don’t Ask | Objects protect their own state |
| Polymorphism | Open/Closed, Dependency Inversion | Enable extension without modification |
| Abstraction | DRY, YAGNI | When and how to abstract |
| Inversion of Control | Dependency Inversion | Framework-controlled flow |
Theory to Practice
Understanding concepts helps you:
- Know WHY principles matter: Not just rules to follow, but mathematical necessities
- Make better tradeoffs: When breaking a principle makes sense
- Evaluate existing code: Measure coupling, cohesion, invariant violations
- Communicate effectively: Discuss design in precise terms
“Stop thinking of SRP, LSP, OCP, Law of Demeter as wishy washy ‘design guidelines’ and start thinking in terms of building bug free programs out of bug free classes. As stated (except for LSP) they are wishy washy. But underneath is the hard steel of ‘class invariant doesn’t hold’ === ‘you have hit a bug’.”
See Also
- Object-Oriented Design - Comprehensive guide to OOP concepts and principles
- Design Principles - Actionable guidelines derived from these concepts
- Software Design - Broader design topics
- Good Software Practices