# Clean Architecture - Component Principles (Part 3)

You could follow the previous posts here:
- [Part 1: Do It Right](https://phamduyhieu.com/clean-architecture-notes-part-1) 
- [Part 2: Design Principles](https://phamduyhieu.com/clean-architecture-notes-part-2) 

If the **SOLID** principles tell us how to arrange the bricks into walls and
rooms, then the component principles tell us how to arrange the rooms into
buildings.

# III. Component Principles

Components are the units of deployment. They are the smallest entities that
can be deployed as part of a system. In Java, they are jar files. In Ruby, they
are gem files. In .Net, they are DLLs.

## 1. Component Cohesion

> 
Focus on the granularity of components and help the developer partition classes into components.


Uncle Bob gave us three principles of component cohesion:
 ### REP: The Reuse/Release Equivalence Principle

- Classes and modules that are grouped together into a component should be releasable together, share the **same version number**, are included under the **same release documentation**
- Classes and modules that are formed into a component must belong to a cohesive group
- If a component should be considered **reusable** it must be a **releasable** unit

### CCP: The Common Closure Principle

- Gather into components those classes that change for the same reasons and at the same times.
- Separate into different components those classes that change at different times and for different reasons.
- this is **Single Responsibility Principle** for components
- A class should not contain multiple reasons to change
- Drive components to be larger


### CRP: The Common Reuse Principle

- Don't force users of a component to depend on things they don’t need
- Drive components to be smaller


![image.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1638809645446/fWAjpFT4qG.png)

## 2. Component Coupling

> 
Focus on the stability and relationship between the components

### Acyclic Dependencies Principle

- Allow no cycles in the component dependency graph

![Acyclic_dependencies,_circular_dependency_example.svg.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1638839530910/2GZBKtOaP.png)

### Stable Dependencies Principle - SDP

- Depend in the direction of stability
- ***I*** : Instability : * **I** = Fan-out / (Fan-in + Fan-out)*

with  *Fan-in* : Incoming dependencies, *Fan-out* : Outgoing depenencies

- **I metric** (Instability) of a component should be larger than the **I metrics** of the components that is depends on
=> **I metrics** should decrease in the **direction of dependency**
- Not all components should be stable

### Stable Abstraction Principle - SAP

- A component should be as **abstract** as it is **stable**
- The software that encapsulates the **high-level policies** of the system should be placed into stable components *(I = 0)*, Unstable components *(I = 1)* should contain only the software that is **volatile** (quickly and easily change)
- A stable component should also be abstract so that its stability does not **prevent it from being extended** (Ex: interface, abstract class)
- **Unstable component** should be **concrete** since its instability allows the concrete code within it to be **easily changed**

with Abstractness **A** = Number of **abstract classes and interfaces** / number of **classes**

> 
Dependencies run in the direction of abstraction

----------------------------------------

----------------------------------------

Uncle Bob also give us the concept **Zones of Exclusion**

![image.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1638807706597/1amJvh9X9.png)

with:
- **Zone of Pain** :  highly stable and concrete component

=> cannot be extended because it is not abstract, very difficult to change because of its stability.

- **Zone of Useless** : maximally abstract, yet has no dependents

=> such components are useless :)))

Good architects strive to position the majority of their components at **endpoints** on the Main Sequence.

=> But in reality, those components have the best characteristics if they are **on**, or **close**, to the Main Sequence.


(to be continued