Skip to content

Instantly share code, notes, and snippets.

@rgkobashi

rgkobashi/Clean Code - SOLID Principles - Video Series Summary.md

Created February 19, 2020 08:20
Show Gist options
  • Star 3 You must be signed in to star a gist
  • Fork 1 You must be signed in to fork a gist
  • Save rgkobashi/c7b4190fb926cb58ccda8f5ae9b6230f to your computer and use it in GitHub Desktop.
Save rgkobashi/c7b4190fb926cb58ccda8f5ae9b6230f to your computer and use it in GitHub Desktop.
Download ZIP
Personal notes/summary of Clean Code SOLID Principles Video Series by Uncle Bob
Raw
Clean Code - SOLID Principles - Video Series Summary.md

Foundations of the SOLID principles (Episode 8)

  • Design smells:
    • Immobility
    • Viscosity: how easy is to add design-preserving code to a system
    • Needles complexity
  • Dependency management principles:
    • SOLID
    • Component cohesion principles
    • Component coupling principles

The Single Responsibility Principle (Episode 9)

  • A responsibility is a source of change for one particular actor, thus they are tight to actors and not individuals
    • Payments -> Lawyers
    • DB operations -> DBAs, architects
    • Reports -> Accountants
  • Colocation of reponsabilities couples actors

The Open-Closed Principle (Episode 10)

  • Software should be open for extension but close for modification
  • Modify by adding new code and not by changing code
  • Do not over engineer the design, it is better to wait for the change and from there see what other things are likely to be changed
  • Big design up front is not good, is hard to modify in the future, agile design is better
  • Design huddles before writing code are useful
  • This principle is the moral center of a system architecture

The Liskov Substitution Principle (Episode 11)

  • This principle is about asymmetry of usability
  • Inheritance for static typed languages and Duck typing for dynamic languages
  • The representative rule
    • Representation of things does not share the relantionships they represent, square/rectangle and divorced/lawyers examples
  • Some violations:
    • If functions of subclass is empty and the parent class implements them
  • Check if it is a type instance:
    • Avoid whenever is possible, only do it when the compiler forgets what it is and you already know
    • This is called typecase, this is likely a violation of this principle

The Interface Segregation Principle (Episode 12)

  • First minutes is a good overview on how to architect an app
  • Dont depend on things you dont need
    • You can have a class inheriting from multiples interfaces/classes
  • Dont force user/caller to know things they dont have to
  • This principle addresses Fat classses problem
  • Interfaces has more to do with the classes that use them than the classes than implementes it

The Dependency Inversion Principle (Episode 13)

  • Inversion of source code dependencieas against flow control
  • A plugin architecture is about inverting dependencies
  • Frameworks follow this principle, since they work as a plugins
  • High level policy should not depend on down level details (DBs, webs, formatting)
  • DBs, UI, etc should be plugin to the application

Solid Case Study (Episode 14)

  • Gather requierement by listening to the customer, consider maming the architecture based on use cases:
    1. Enumerate use cases
    2. List entities
    3. Define data structures (including bussines rules)
    4. Define actors/modules so you can partitionate
  • Casting might be needed to dont violate The Liskov Substitution Principle
  • Too many interfaces are not bad, they do not have executable code
  • One aproach to break dependencies between modules apart of using interfaces, is to write builders (i.e. requests) and factorys (i.e. use cases)
  • Class diagrams:
    • Useful to share thought process to other people
    • They are very easy to get outdated and rot
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment