SOLID Components (Episode 15)

Differences beetween libraries and frameworks
- Application calls subroutines libraries
- Framework calls application
Component: independant deployable library
When designing components is important to identify actors in order to split responsibilities
When describing behavior modules avoid saying low level words, instead use abstractions
Good episode in how to design modules

Component Cohesion (Episode 16)

When classes uses something, same compoennet
When classes implements something, different component
The goal is independent deployability
Release Reuse Equivalence Principle
- Components should be manage by a release cycle
- Components needs to be large enought to manage release cycles
Common Closure Principle
- Group classes that change for same reasons
- A class should have only one reason to change
- Reasons are Single Responsabiloty Principle
Common Reuse Principle (related to Interface Segregation Principle)
- Avoid making components that depend on classes they dont use
You cannot satisfy all 3 principles at the same time (Tension Diagram)
Make components as cohesive as possible

Acyclic Dependencies Principle
- There should be no cycles in the component dependency graph
- Arrows should point down always
To remove cycles:
- Split components
- Use Dependency Inversion Principle
Stable Dependencies Principle
- Stable components
  - When is hard to change
  - Incoming dependencies
- Unstable componentes
  - When is easy to change
  - Outgoing dependencies: when component depends on others
  - Should depend on stable components
  - Code that changes frequently should be here
When someone changes something that you depend on, make sure it hurts them more than you
Measures
- Inestability (I)
  - Afferent couplings (Ca) / fan in / incoming dependencies
  - Efferent couplings (Ce) / fan out / outgoing dependencies
  - I = Ce / (Ca + Ce)
    - The result is a ratio between 0 and 1: 0 stable, 1 unstable
- Abstractness (A)
  - A = Abstract classes / Total classes
- Ideally A + I = 1
- Distance (D)
  - D = | A + I - 1 |
  - The lower the better
- These metrics on systems you are not familiar with can be very useful
Dependencies should point in direction to decrease inestability
Stable Abstractions Principle
- The more stable a component is, the more abstract should be
- The more stable components are on the bottom
- The stuff that is at the top is concrete, the stuff at the bottom is abstract