Software Design Principles

Module 1

SOLID Principles

Five class-level design principles, taught by the failure each one prevents — and an honest account of which of them actually changes an architecture.

45 min3 lessons
Start module

What you will be able to do

  • State each SOLID principle in terms of the change it makes cheap.
  • Identify single-responsibility violations by counting the stakeholders who request changes, not the lines a file contains.
  • Recognise Liskov and interface-segregation violations from their runtime symptoms.
  • Apply dependency inversion at a module boundary and explain why it is the architectural member of the set.
  • Judge when applying a principle costs more than the failure it prevents.

  1. 01One Reason to Change, and Extension Without Edits

    The single-responsibility and open-closed principles, restated as questions you can answer about a real file: who asks for changes here, and what does adding the next variant cost?

  2. 02Substitution and Interface Size: LSP and ISP

    Two principles about promises: Liskov is about honouring the promise a type makes, and interface segregation is about not forcing implementers to promise what they cannot deliver.

  3. 03Dependency Inversion: The Architectural One

    Four of the five principles improve a class. This one changes the shape of a system, decides what can be tested without infrastructure, and determines what can later be extracted.

SOLID Principles

6 questions · pass at 75%