L'idea principale che sta dietro la Programmazione ad Oggetti risiede, in buona parte, nel mondo reale. Come spesso accade, gli esempi pratici forniscono una comprensione più chiara ed immediata della teoria e, pertanto, si userà tale approccio per fissare bene in mente i concetti basilari del mondo OOP.
Si prenda in considerazione un comune masterizzatore, come quelli ormai diffusi nella stragrande maggioranza dei moderni PC. Di tale oggetto si conoscono le sue caratteristiche ma quasi nessuno (se non coloro che lo hanno progettato e assemblato) è a conoscenza dei componenti elettronici e dei sofisticati meccanismi che ne regolano il corretto funzionamento, ne' a qualcuno salterebbe in mente di smontare un masterizzatore prima di acquistarlo per vedere come è fatto all'interno (supposto che il negoziante sia disposto ad accettare una tale richiesta, decisamente fuori dal comune!).
Il concetto che sta dietro alla programmazione ad oggetti nasce dallo stesso principio: ciò che importa non è l'implementazione interna del codice (che corrisponde ai componenti elettronici, nel caso del masterizzatore) ma, piuttosto, le caratteristiche e le azioni che un componente software è in grado di svolgere e che mette a disposizione (espone) all'esterno.
Dunque, con riferimento a quanto gia detto in precedenza, un programma che segue il paradigma OOP è costituito da un numero variabile di tali componenti, che ora denominiamo oggetti, i quali interagiscono tra di essi attraverso lo scambio di messaggi.
Proseguendo nell'esempio del masterizzatore e supponendo di voler implementare un oggetto software che ne gestisca le funzionalità, potremmo iniziare a definirne le caratteristiche. Ad esempio:
- Marca
- Velocità di scrittura su supporti CD-R
- Velocità di scrittura su supporti CD-RW
- Velocità di lettura
- Interfaccia
- Dimensione del buffer dati
Mentre, per quanto riguarda le azioni potremmo considerare le seguenti:
- Scrivi su CD
- Scrivi su DVD
- Leggi CD
- Espelli CD
In parole molto semplici, potremmo dire che le azioni altro non sono che "le cose che un oggetto è in grado di fare" mentre le sue caratteristiche rappresentano i dati che le azioni stesse possono utilizzare per eseguire le operazioni che da esse ci si aspetta.
In OOP, le caratteristiche di un oggetto vengono denominate proprietà e le azioni sono dette metodi. Questi sono due concetti fondamentali ed è molto importante che siano ben chiari prima di introdurre nuove definizioni.
Altrettanto importante, però, è ribadire il contesto in cui abbiamo iniziato a ragionare: non dobbiamo pensare più ad un programma che racchiuda tutto in un unico grande calderone ma dobbiamo iniziare a pensare "ad oggetti". Dobbiamo, cioè, essere in grado di identificare gli oggetti che entrano in gioco nel programma che vogliamo sviluppare e saperne gestire l'interazione degli uni con gli altri.
In un programma di tipo procedurale, si è soliti iniziare a ragionare in maniera top-down, partendo cioè dal main e creando mano a mano tutte le procedure necessarie. Tutto questo non ha più senso nella programmazione ad oggetti, dove serve invece definire prima le classi e poi associare ad esse le proprietà ed i metodi opportuni.
Nella guida UML, si fa riferimento (dove si parla del Rapid Application Development) al metodo utilizzato durante l'analisi progettuale per identificare in modo ottimale le classi da utilizzare.