👨‍💻
Software Engineering
Clean Architecture
Clean Architecture
  • Overview
  • Foreword
  • Preface
  • Part 1
    • Introduction
    • 1: Design & Architecture
    • 2: A Tale of Two Values
  • Part 2: Programming Paradigms
    • 3: Paradigm Overview
    • 4: Structured Programming
    • 5: Object-Oriented Programming
    • 6: Functional Programming
  • Part 3: Design Principles
    • Intro
    • 7: Single Responsibility Principle
    • 8: Open-Closed Principle
  • Part 5: Architecture
    • 22: Clean Architecture
Powered by GitBook
On this page
  • SOLID Principles
  • What is the goal?
  • Summary
  • SRP: The Single Responsibility Principle
  • OCP: Open-Closed Principle
  • LSP: Liskov Substitution Principle
  • ISP: Interface Segregation Principle
  • DIP: Dependency Inversion Principle
  1. Part 3: Design Principles

Intro

Good software systems begin with clean code

If the Bricks aren't well made, then the architecture of the building doesn't matter.

SOLID Principles

They tell us how to arrange our functions and data structures into classes, and how those classes should be interconnected.

What is the goal?

The goal of SOLID is the creation of mid-level software (modules) structures that:

  1. Tolerate Change

  2. Are easy to understand

  3. Are the basis of components that can be used in many software systems.

Summary

SRP: The Single Responsibility Principle

An active corollary to Conway's Law: The best structure for a software system is heavily influenced by the social structure of the org that uses it so that each software module has one, and only one, reason to change.

OCP: Open-Closed Principle

Bertrand Meyer in 1980s. For software systems to be easy to change, they must be designed to allow the behavior of those systems to be changed by adding new code, rather than changing existing code.

LSP: Liskov Substitution Principle

Barbara Liskov's famous definition of subtypes from 1988. To build software systems from interchangeable parts, those parts must adhere to a contract that allows those parts to be substituted one for another.

ISP: Interface Segregation Principle

Advises software designers to avoid depending on things they don't use.

DIP: Dependency Inversion Principle

Code that implements a high-level policy should not depend on the code that implements the low-level details. Instead, details should depend on policies (abstractions).

Previous6: Functional ProgrammingNext7: Single Responsibility Principle

Last updated 9 months ago