architettura e solid

principi solid

SOLID aiuta a costruire codice estendibile: classi con responsabilità singola, dipendenze invertite e interfacce minimali.

• Single responsibility: una classe, un motivo di cambio.
• Open/closed: estendi senza modificare.
• Liskov: sostituzioni sicure.
• Interface segregation: contratti piccoli.
• Dependency inversion: dipendi da astrazioni.

layering

separa controller, service, repository e dominio. ogni layer ha confini e test dedicati.

api/
  controller/
  service/
  repository/
  domain/

design pattern

test e dependency injection

inietta dipendenze via costruttore per semplificare mock e test unitari.

class BillingService {
    private final PaymentGateway gateway;

    BillingService(PaymentGateway gateway) {
        this.gateway = gateway;
    }
}

package e moduli

• raggruppa per feature, non per tipo.
• esponi solo API pubbliche, nascondi dettagli interni.
• documenta contratti con javadoc.

checklist finale

• responsabilità singole e ben definite.
• dependency injection ovunque serve test.
• pattern usati solo quando risolvono un problema reale.
• documentazione delle scelte architetturali.

panoramica

In questo capitolo su architettura e solid, progetta servizi enterprise con responsabilità chiare e test rapidi. L'obiettivo è trasformare i concetti in micro-pattern riutilizzabili con esempi piccoli e verificabili.

Lavora in sequenza: leggi, prova, modifica gli snippet e annota i trade-off principali (performance, leggibilità, manutenzione).

obiettivi

• capire e applicare principi solid in uno scenario reale
• capire e applicare layering in uno scenario reale
• capire e applicare design pattern in uno scenario reale
• capire e applicare test e dependency injection in uno scenario reale

scheda rapida

import java.util.List;

public class Main {
  public static void main(String[] args) {
    var dati = List.of(1, 2, 3);
    var out = dati.stream().map(x -> x * 2).toList();
    System.out.println(out);
  }
}

Adatta questo scheletro agli esempi della lezione e sostituisci i dati con il tuo dominio.

tips

• organizza package per dominio
• preferisci immutabilità dove possibile
• documenta le API pubbliche
• SRP: una ragione di cambiamento
• OCP: estendi senza modificare
• DIP: dipendi da astrazioni

mini progetto

Refactor di una classe monolitica.

• identifica responsabilità
• separa in classi
• introduci interfacce
• scrivi test regressione

output atteso: uno script o query ripetibile con risultati verificabili.