Per esporre le motivazioni che hanno portato alla programmazione a oggetti, consideriamo come esempio una possibile implementazione di un insieme di interi:
e alcune classi che lo utilizzano (le quali appartengono ipoteticamente ad altre applicazioni):
In quest'implementazione di InsiemeDiInteri, le variabili utilizzate per la gestione dei dati sono dichiarate public, quindi le applicazioni che usano tale insieme vengono implementate in base alla sua rappresentazione.
Se tale rappresentazione viene cambiata (ad esempio, usando una lista concatenata invece di un array), pur mantenendo il significato inalterato, sono necessarie modifiche estese al codice delle altre applicazioni.
In particolare, vanno modificate tutte e solo le istruzioni che facevano riferimento alla vecchia struttura dati. Questo intervento richiede tempo e sforzo che sono decisamente mal spesi, e inoltre può introdurre degli errori.
Se più funzioni possono accedere ai dati liberamente, aumentano le possibilità di avere problemi di correttezza nell'uso e nella modifica delle informazioni.
Ad esempio, considerando la rappresentazione basata su array di InsiemeDiInteri, per eliminare un dato sarebbe necessario sfruttare l'indice di riempimento n, ma nella classe GestioneContiCOrrenti viene ****invece usata una convenzione diversa, non compatibile, che provede di sostituire il dato eliminato con uno 0. Di conseguenza, eventuali altri metodi che operano su insiemeConti potrebbero considerare i valori 0come conti validi.
Nell'implementazione delle classi che usano InsiemeDiInteri, lo stesso codice per la ricerca è stato scritto tre volte (cercaTarga, cercaMatricolae cercaConto). Supponendo che tale codice sia stato copiato e incollato, per evitare di doverlo riscrivere da zero ogni volta, rimane comunque un problema: se esso contiene errori, questi dovranno essere corretti manualmente in ciascuno dei tre metodi.
La soluzione è definire InsiemeDiInteri come un tipo di dato astratto. Esso: