You could follow the previous posts here:

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

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

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

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

Clean Architecture - Component Principles (Part 3)

Comments

More from this blog

Review Singapore sau 5 tháng

Domain Driven Design - Healthcare Platform Example

Domain Driven Design Introduction

The Anatomy of a Unit Test

2024 Recap

III. Component Principles

1. Component Cohesion