PRINCIPLES

S - Single Responsibility Principle

Ogni modulo o funzione dovrebbe avere una sola responsabilità ben definita. Una classe dovrebbe avere un solo motivo per cambiare.

Il Problema

Classi che fanno troppe cose (God Object) sono difficili da testare, manutenere e riutilizzare. Ogni modifica rischia di rompere funzionalità non correlate.

La Soluzione

Separare responsabilità in classi/moduli distinti. Ogni componente si occupa di una sola cosa e la fa bene.

Struttura

Classi piccole e focalizzate. Ogni classe gestisce un singolo aspetto (persistenza, validazione, rendering, logica business).

Partecipanti:
Classe focalizzata - una sola responsabilità
Client - compone classi specializzate
Esempi di Codice

PROBLEMA: Violazione SRP

Classe con multiple responsabilità: validazione, persistenza, rendering. Difficile da testare.

JAVASCRIPT
Loading...

SOLUZIONE: Single Responsibility (SRP)

Ogni classe ha una sola responsabilità. Testabile, riutilizzabile, manutenibile.

JAVASCRIPT
Loading...
Esempi nel Mondo Reale
Repository pattern (separazione persistenza da logica)
Service layer (business logic separata da controller)
Validator classes (validazione isolata)
React components (presentational vs container)
Quando Usarlo
Sempre: ogni classe dovrebbe avere un solo scopo
Quando una classe cambia per motivi diversi
Per migliorare testabilità e riutilizzo
Quando NON Usarlo
Non frammentare troppo se la complessità non lo richiede
Pattern Correlati
RepositoryService LayerFacade