Separazione delle responsabilità

Finora abbiamo costruito i mattoni fondamentali del nostro piccolo motore di gioco: abbiamo definito le classi (Player, Weapon e Potion), ci siamo preoccupati di proteggere i dati tramite l’incapsulamento e abbiamo gestito le situazioni impreviste con le eccezioni. Se qualcosa non ti è chiaro o non hai completato gli esercizi precedenti, ti conviene fermarti un attimo e recuperare: da qui in avanti questi elementi saranno indispensabili.

Riassumendo ciò che abbiamo già realizzato:

Player: il personaggio, con punti vita, forza e destrezza.
Weapon: l’arma che infligge danni casuali.
Potion: gli oggetti consumabili per curarsi o potenziarsi.

Se però guardiamo al codice dentro main.py, salta fuori un problema evidente: tutto è mescolato. Il file gestisce i calcoli, stampa messaggi, controlla i turni e potrebbe perfino chiedere l’input all’utente. Funziona, ma è un miscuglio poco elegante e soprattutto poco flessibile.

È il momento di fare ordine creando una vera e propria architettura software.

Il principio SOLID (introduzione)

Quando le applicazioni crescono, non basta che funzionino: devono anche essere facili da capire, modificare ed estendere. Per questo motivo, nel tempo sono stati definiti alcuni principi di progettazione noti con l’acronimo SOLID.

SOLID raccoglie cinque linee guida che aiutano a scrivere codice più pulito, più flessibile e meno fragile:

S – Single Responsibility Principle
O – Open/Closed Principle
L – Liskov Substitution Principle
I – Interface Segregation Principle
D – Dependency Inversion Principle

In questa lezione ci concentreremo solo sulla S, il principio di responsabilità singola. Le altre lettere verranno introdotte più avanti, quando avremo una base sufficiente per comprenderle senza trasformarle in formule magiche da memorizzare.

Separazione delle responsabilità

Il principio SOLID (introduzione)

S – Single Responsibility Principle (SRP)