Software Design Principles
Software design principles are guidelines such as SOLID, DRY, KISS, and YAGNI that help programmers structure code so it stays easy to understand and change, instead of turning brittle and tangled as a system grows.
itSoftware engineering | OpenSkills.info
Course pathWalk it in order
Look it upDip in anytime
Go furtherLeaves this page
Intro
Software Design Principles
A working program is not the same thing as a well-designed one. Design principles are the accumulated judgment of the software field about which structures keep a codebase changeable, and which ones quietly make every future change more expensive. You apply them while writing a class, reviewing a pull request, or deciding how to split a module — not as a one-time architectural decision, but as a running habit.
None of these principles are laws of nature. They are heuristics distilled from decades of watching systems succeed and fail. Treat them as a shared vocabulary for describing why one design is easier to live with than another, and as a set of questions to ask before you commit to a structure.
Why design principles exist
Software costs money twice: once to write, and continuously to change. Requirements shift, teams rotate, and the parts of a system that seemed unrelated on day one turn out to depend on each other by year two. Design principles exist to keep the second cost from spiraling.
Two forces drive that cost more than any other: how much of the system you have to understand to make one change, and how far a change ripples once you make it. Every principle in this course is really an answer to one of those two problems.
The foundational lens: separation of concerns
In 1974, Edsger Dijkstra described the discipline of studying one aspect of a problem "in isolation for the sake of its own consistency," while still knowing that other aspects exist and matter. He called this the separation of concerns, and called it "the only available technique for effective ordering of one's thoughts."
Continue the course
This section is part of the paid course.
See pricing to subscribe, or log in if you already have access.
Where this skill leads
Relevant careers
See how this topic contributes to broader role-level skill maps.
Sources
- https://www.cs.utexas.edu/~EWD/transcriptions/EWD04xx/EWD447.html
Supports
- Dijkstra's 1974 coining of "separation of concerns" and its definition as studying one aspect of a problem in isolation
- The idea that separation of concerns underlies the other principles in this course
- Quiz question 1 (separation of concerns)
- https://en.wikipedia.org/wiki/Coupling_(computer_programming)
Supports
- Definition of coupling as interdependence between modules
- Low coupling correlating with maintainability and reuse
- Attribution to Larry Constantine and Structured Design, 1974
- https://en.wikipedia.org/wiki/Cohesion_(computer_science)
Supports
- Definition of cohesion as how well the elements inside a module belong together
- High cohesion correlating with maintainability, reuse, and reliability
- Attribution to Larry Constantine and Structured Design, 1974
- https://blog.cleancoder.com/uncle-bob/2014/05/08/SingleReponsibilityPrinciple.html
Supports
- Single Responsibility Principle definition ("one and only one reason to change")
- Framing of "reason to change" around distinct stakeholders
- Quiz questions 2 and 5 (SRP)
- https://blog.cleancoder.com/uncle-bob/2014/05/12/TheOpenClosedPrinciple.html
Supports
- Open-Closed Principle definition (extend without modifying existing code)
- Plugin architectures (editors, IDEs) as a practical example of OCP
- Quiz question 6 (OCP)
- https://en.wikipedia.org/wiki/SOLID
Supports
- Summary definitions of all five SOLID principles, including Liskov Substitution, Interface Segregation, and Dependency Inversion
- Attribution of SOLID's original principles to Robert C. Martin, 2000, and the acronym to Michael Feathers, circa 2004
- Open-Closed Principle's attribution to Bertrand Meyer, 1988
- Quiz questions 7, 8, and 9 (LSP, ISP, DIP)
- https://en.wikipedia.org/wiki/Don%27t_repeat_yourself
Supports
- DRY principle definition ("single, unambiguous, authoritative representation")
- Attribution to Andy Hunt and Dave Thomas, The Pragmatic Programmer, 1999
- Quiz questions 3 and 10 (DRY)
- https://pragprog.com/titles/tpp20/the-pragmatic-programmer-20th-anniversary-edition/
Supports
- Confirmation of The Pragmatic Programmer as the book coining DRY, by David Thomas and Andrew Hunt
- Publisher and book scope (broad pragmatic software-development practices)
- https://en.wikipedia.org/wiki/KISS_principle
Supports
- KISS principle definition (prefer the simplest design)
- Origin attributed to Kelly Johnson at Lockheed's Skunk Works
- Quiz question 4 (KISS)
- https://martinfowler.com/bliki/Yagni.html
Supports
- YAGNI principle definition (don't build for a need you only anticipate)
- Origin in Extreme Programming, Kent Beck and Chet Hendrickson, the C3 project
- The four costs of building ahead of need (build, delay, carry, repair)
- YAGNI's dependence on malleable, refactorable, well-tested code
- Quiz question 11 (YAGNI)
- http://www.ccs.neu.edu/home/lieber/LoD.html
Supports
- Law of Demeter definition ("only talk to your friends")
- Origin at Northeastern University's Demeter Project, 1987, led by Ian Holland
- Quiz question 12 (Law of Demeter)
- https://en.wikipedia.org/wiki/Composition_over_inheritance
Supports
- Composition over inheritance definition and the is-a vs. has-a framing
- Attribution to the Design Patterns (Gang of Four) book, 1994
- Runtime flexibility of composition vs. compile-time binding of inheritance
- https://www.pearson.com/en-us/subject-catalog/p/design-patterns-elements-of-reusable-object-oriented-software/P200000009480/9780321700698
Supports
- Canonical authorship and publication of Design Patterns by Gamma, Helm, Johnson, and Vlissides
- Its role as the origin of the composition-over-inheritance guidance and the broader pattern catalog
- https://martinfowler.com/bliki/BeckDesignRules.html
Supports
- Kent Beck's Four Rules of Simple Design and their priority order (passes tests, reveals intention, no duplication, fewest elements)
- Awesome-links rationale for Kent Beck's Four Rules of Simple Design
- https://cupid.dev/
Supports
- CUPID as Dan North's 2022 alternative to SOLID and its five named properties
- Awesome-links rationale for CUPID
- https://www.elegantobjects.org
Supports
- Elegant Objects' prohibitions (null, getters/setters, static methods, mutable objects, implementation inheritance)
- Awesome-links rationale for Elegant Objects
- https://www.archunit.org
Supports
- ArchUnit as a Java library for testing architectural rules (layering, dependencies, cycles) as executable unit tests
- Awesome-links rationale for ArchUnit
- https://github.com/sverweij/dependency-cruiser
Supports
- dependency-cruiser as a tool for validating and visualizing JavaScript/TypeScript module dependencies against configurable rules
- Awesome-links rationale for dependency-cruiser