Tutti i metodi visti finora spingono verso una ben precisa direzione:

ottenere una forte astrazione, nascondere l’informazione all’interno dei moduli, spezzare il problema in parti via via più semplici.

Analizzando in dettaglio si può vedere come questa operazione venga svolta sia nella definizione dei programmi, puntualizzando la coesione dei moduli e il loro interfacciamento sia rispetto ai dati, dove il processo di normalizzazione tende a creare un archivio per ogni entità e a ridurre tutto a riferimenti tramite chiavi.

Da questo punto di vista la progettazione orientata agli oggetti presenta degli innegabili vantaggi rispetto alla programmazione strutturata presentata fino a questo momento.

L’astrazione, il concetto di protezione dell’informazione (information hiding), e la modularità sono sempre inseguiti con fatica dai metodi strutturati, perchè si parte da un punto completamente libero per poi creare una "gabbia" modulare in un secondo momento.

Pensare ad oggetti invece porta in modo naturale ad ottenere queste caratteristiche, non solo nel riguardo delle procedure, ma anche dei dati!

La progettazione ad oggetti introduce due nuovi concetti rispetto a quelli visti finora: la possibilità di includere dati all’interno di un modulo e il meccanismo dei messaggi.

La strutturazione prevede delle variabili globali e delle variabili locali di ogni procedura. Nel paradigma ad oggetti non esistono più variabili, ma attributi di ogni oggetto. Degli attributi possono restare nascosti all’interno dell’oggetto anche se sono poi trattati dall’ oggetto stesso come variabili globali, gli altri oggetti potranno accedervi solo attraverso i metodi pubblici creati appositamente.

In questo modo vengono ridotti gli interfacciamenti "cattivi" tramite variabili globali, spostandoli verso degli interfacce "buone" basate su passaggio di parametri.

Ma il nuovo concetto che rompe con la programmazione strutturata è quello di messaggio. Un oggetto chiede servizi ad un altro mandando un "messaggio", un modulo chiede servizi ad un altro modulo "chiamandolo". A prima vista questa distinzione sembra solo un sofistico gioco di parole, invece racchiude in se tutta la potenza della nuova visione.

Nella visione strutturata c’è un’idea di processore, e quindi di "controllo" che passa da un modulo all’altro. Un modulo viene eseguito, chiama un altro modulo a cui passa temporaneamente il controllo e così via. Un modulo risolve un problema grosso, distribuendolo poi nelle "sue" sottoparti; il meccanismo mentale è che un sottomodulo "appartiene" al modulo a livello superiore.

Nella visione ad oggetti ogni oggetto chiede un servizio ad un altro oggetto. Non c’è più l’idea di controllo e di appartenenza o gerarchia di moduli. Quando un modulo chiede un servizio ad altri, resta in sospeso finchè l’oggetto fornisce una risposta. Un oggetto non appartiene ad un altro, ma esiste come entità con una propria logica.

Dal punto di vista pratico cambiano pochissime cose, ma abbracciando questi punti di vista si ottengono le qualità ricercate in modo semplice e naturale.

La fase di analisi riporta verso la progettazione una gerarchia di classi ed una prima stesura delle istanze e di come queste debbano comunicare tra loro attraverso messaggi. La progettazione non fa altro che raffinare questo processo entrando nei dettagli delle varie classi.

Nella figura vediamo un diagramma di Booch. In alto a sinistra vediamo un oggetto, rappresentato da un rettangolo sovrastato dal proprio nome. Dei piccoli rettangoli sulla sinistra evidenziano i metodi e gli attributi visibili dall’esterno, mentre la struttura interna è rappresentata da una nuvoletta che nasconde ogni dettaglio.

Nella parte destra vediamo due oggetti, "Gestione ordini" e "Gestione Articoli". La gestione ordini sfrutta i metodi "Esiste articolo?" e "Varia giacenza" per portare a termine il propri metodi "Inserisci" ed "Evadi".

I metodi necessari sono la gestione di archivi, la gestione di transazioni tra queste e gli eventi che scatenano parti di programma.

Le classi si riducono a Archivi Anagrafici, Archivi di Movimentazione, Archivi Tabellari, Stampe e Programmi Batch.

Questa carrellata sui metodi di progettazione ha evidenziato che esistono dei metodi di progettazione per gli archivi, dei metodi di progettazione per le procedure e che le qualità da perseguire nel passaggio delle specifiche di analisi in architettura di programma sono l’astrazione, la modularità e la protezione dell’informazione.

Di particolare rilievo sono le tecniche di

Normalizzazione degli archivi

divisioni in moduli dei programmi.