Beyond Objects
Questo articolo sostiene che il principio fondamentale dell'orientamento agli oggetti di mappare direttamente la funzionalità del sistema sugli individui del dominio del problema sia intrinsecamente difettoso e porti alla frammentazione, proponendo invece di abbandonare l'orientamento agli oggetti a favore di un approccio che scolleghi gli individui del dominio dai moduli funzionali.
Articolo originale sotto licenza CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo
L'Idea Centrale: L'Errore del "Taglia Unica"
Immagina di costruire una casa. Per gli ultimi 50 anni, la regola standard nella costruzione di software è stata: "Ogni stanza della casa deve essere gestita dalla persona che ci vive."
Nel mondo del software, questo viene chiamato Programmazione Orientata agli Oggetti (OOP). L'idea è che se hai un "Utente" nel mondo reale, crei un "Oggetto Utente" nel codice. Questo oggetto dovrebbe contenere tutti i dati relativi a quell'utente (il suo nome, la password) e svolgere tutto il lavoro relativo a lui (effettuare l'accesso, scrivere recensioni, prenotare tavoli).
Daniel Jackson sostiene che questa regola sia una trappola. Sembra logica, ma in pratica costringe il software a diventare un groviglio confuso. Suggerisce di smettere di cercare di stipare ogni lavoro dentro la "persona" e di organizzare invece il software in base a ciò che sta accadendo (le azioni), non a chi lo sta facendo (gli individui).
Il Problema: Il "Coltellino Svizzero" vs. Lo "Strumento Specializzato"
Jackson afferma che forzare ogni compito su un singolo "Oggetto Utente" causa due problemi principali:
1. Il Problema del "Coltellino Svizzero" (Conflazione)
Immagina che un Oggetto Utente sia un coltellino svizzero. Ha una lama, un cacciavite, un cavatappi e uno stuzzicadenti.
- Il Problema: Se vuoi usare il cavatappi (per gestire la password di un utente), devi portare con te tutto il pesante coltello. Se vuoi cambiare la lama (correggere un bug nel sistema delle recensioni), potresti accidentalmente rompere il cavatappi.
- Nel Software: Un oggetto "Utente" finisce per contenere la password dell'utente, la sua cronologia delle recensioni, le sue impostazioni di notifica e la sua logica di prenotazione, tutto in un unico file gigante. Se vuoi cambiare il modo in cui funzionano le recensioni, devi scavare nel codice delle password. È disordinato e difficile da riparare.
2. Il Problema delle "Troppe Mani" (Frammentazione)
Immagina un compito come "Prenotare un tavolo".
- Il Problema: Chi deve farlo? L'Utente? Il Ristorante? Il Tavolo? La Prenotazione?
- Nel Software: Poiché la regola dice "assegna il compito all'oggetto", il codice viene frammentato. L'oggetto "Utente" controlla se ha una prenotazione. L'oggetto "Ristorante" controlla se il tavolo è libero. L'oggetto "Prenotazione" crea il biglietto.
- Il Risultato: Per effettuare una singola prenotazione, il computer deve far lavorare tre persone diverse in tre stanze diverse e farle parlare tra loro. Se una persona dimentica di parlare all'altra, il sistema si rompe. Questo si chiama frammentazione.
L'Analogia: La Prenotazione al Ristorante
Jackson usa un ristorante per spiegare il concetto.
Il Vecchio Modo (Orientato agli Oggetti):
Hai un oggetto "Utente" e un oggetto "Ristorante".
- Quando Alice vuole prenotare un tavolo, chiede al suo oggetto "Utente".
- L'oggetto Utente chiede all'oggetto "Ristorante" se un tavolo è libero.
- L'oggetto Ristorante chiede all'oggetto "Slot" (Posto).
- Viene creato l'oggetto "Prenotazione".
- Il Disordine: Se vuoi cambiare la regola in modo che "Alice non possa prenotare due tavoli contemporaneamente", devi aggiornare l'oggetto Utente, l'oggetto Ristorante e l'oggetto Prenotazione. Sono tutti intrecciati tra loro.
Il Nuovo Modo (Concetti):
Invece di chiedere "Chi possiede questo?", chiediamo "Di quale gruppo di regole si tratta?".
Jackson propone di organizzare il software in Concetti. Pensa a un Concetto come a un team specializzato o a un dipartimento in un'azienda, piuttosto che a una persona.
- Concetto 1: "Prenotare"
- Questo team gestisce tutte le regole riguardanti l'impegno preso. Non gli importa chi sia l'utente; gli interessa solo l'atto di prenotare. Contiene l'elenco di chi ha prenotato cosa.
- Concetto 2: "Disponibilità"
- Questo team gestisce l'atto di controllare se un tavolo è libero. Non gli importa chi stia prenotando; gli interessano solo gli slot (i posti).
- Concetto 3: "Autenticazione Utente"
- Questo team controlla solo se la persona è chi dice di essere.
Come lavorano insieme:
Invece dell'oggetto Utente che chiama l'oggetto Ristorante, questi "Concetti" comunicano tra loro attraverso delle Sincronizzazioni (come un semaforo).
- Regola: "Quando arriva una Richiesta, controlla se la Disponibilità dice 'Sì' e se l'Autenticazione dice 'Vai', allora la Prenotazione può effettuare la prenotazione."
Perché questo è meglio
- Nessun Nodo Intrecciato: Il team "Prenotazione" non ha bisogno di sapere come controllare una password. Il team "Autenticazione" non ha bisogno di sapere come controllare un tavolo. Sono separati.
- Nessuna Discussione su "Chi Possiede Cosa": Non devi discutere se il pulsante "cancella" appartenga all'Utente o alla Prenotazione. Ti basta inserire la logica di "cancellazione" nel Concetto che gestisce lo stato della prenotazione.
- Mappe più Chiare: Se guardi il codice, vedi chiaramente le regole di business (Prenotazione, Disponibilità), invece di una mappa confusa di chi possiede quali dati.
Il "Concetto" vs. L'"Oggetto"
- Oggetto: Una piccola macchina che cerca di essere tutto (Dati + Logica + Identità). È come una persona che cerca di essere chef, cameriere e cassiere allo stesso tempo.
- Concetto: Un modulo che gestisce un lavoro o una relazione specifica. È come un dipartimento specializzato. Il "Dipartimento Chef" gestisce la cucina; il "Dipartimento Camerieri" gestisce il servizio. Coordinano le attività, ma non si fondono in un'unica persona.
Conclusione
Jackson non sta dicendo di buttare via tutto il software. Sta dicendo che la regola fondamentale della Programmazione Orientata agli Oggetti — "Assegna ogni lavoro alla persona a cui appartiene" — è la radice del problema.
Passando ai Concetti, smettiamo di cercare di forzare il software a sembrare una collezione di persone. Invece, lo organizziamo come una collezione di regole e relazioni. Questo rende il codice più facile da leggere, più facile da riparare e meno propenso a rompersi quando si prova a cambiare una piccola cosa.
È un ritorno a un modo di pensare più vecchio e semplice (come i database relazionali), ma aggiornato alle esigenze del software moderno, permettendoci di costruire sistemi meno fragili e più logici.
Sommerso dagli articoli nel tuo campo?
Ricevi digest giornalieri degli articoli più recenti corrispondenti alle tue parole chiave di ricerca — con riassunti tecnici, nella tua lingua.