Pensiero Orientato agli Oggetti

Orientato agli Oggetti è una frased'effetto. Dire che qualcosa è object oriented,può farvi apparire più intelligenti. Rubypretende di essere un linguaggio di scripting orientato aglioggetti; ma cosa significa esattamente "objectoriented" ?

Ci sono state molte risposte a questa domanda, e quasi tutteprobabilmente dicono più o men la stessa cosa. Invecedi riassumere velocemente, pensiamo per un momento alparadigma di programmazione tradizionale.

Tradizionalmente, un problema di programmazione èattaccato creando inizialmente una sorta dirappresentazione dei dati , e procedure cheoperino con quei dati. Con questo modello, i dati sonoinerti, passivi, e non sono d'aiuto; esso si appoggia suun largo corpo procedurale , che è attivo , logico, edonnipotente.

Il problema con questo approccio è che i programmisono scritti da programmatori , che sono esseri umani epossono mantenere in testa solo un certo numero di dettagliper volta. Man mano che un progetto diventa più grande, il suo cuore procedurale cresce fino al punto in cuiè difficile ricordare come funziona il tutto. Minimemancanze di ragionamento ed errori di digitazione causanoerrori praticamente introvabili. Interazioni complesse e nondesiderate cominciano ad emergere man mano che il nucleoprocedurale cresce, ed il mantenimento diventa simile alportare in giro una seppia arrabbiata senza che i tentacoliti tocchino la faccia. Ci sono delle linee guida per laprogrammazione che aiutano a minimizzare ed a localizzare ibug all'interno del paradigma tradizionale , mac'è una soluzione migliore che richiedecambiamenti sostanziali al modo in cui lavoriamo .

Quello che la programmazione orientata agli oggetti faè la delegazione degli aspetti logici piùripetitivi ai dati stessi; esso cambia il nostroconcetto di dati da passivo ad attivo.Detta in un altro modo,

  • Smettiamo di trattare ogni blocco di dati come una scatola con un lato aperto che ci permette di metterci le mano dentro e tirare in giro la roba .

  • Cominciamo a trattare ogni blocco di dati come una macchina attiva e ben chiusa con un certo numero di bottoni e quadranti ben etichettati .

Ciò che viene descritta qui sopra come una"macchina" può essere internamente moltocomplessa o molto semplice; non possiamo dirlodall'esterno, e non permettiamo nemmeno a noi stessi diaprire la macchina (eccetto quando siamo assolutamente certiche ci sia qualcosa che non va nel suo progetto), dunque ciè richiesto di fare cose come attivare gliinterruttori e leggere i quadranti per interagire con i dati.Una volta che la macchina è stata costruita , nonvogliamo pensare di nuovo a come funziona.

Potreste pensare che ci stiamo causando solo un maggiorlavoro, ma questo approccio tende ad essere un buon lavoronel prevenire che tutto quanto vada male.

Cominciamo con un esempio che è troppo semplice peressere di valore partico, ma che dovrebbe illustrare almenoin parte il concetto. La vostra macchina un uncontachilometri. Il suo lavoro è tenere traccia delladistanza che la macchina ha percorso dall'ultima voltache il suo bottone reset è stato premuto. Comemodellereste una cosa del genere in un linguaggio diprogrammazione? In C, il contachilometri sarebbe soltanto unavariabile numerica , magari di tipo float. Ilprogramma manipolerebbe quella variabile aumentando il suovalore di poco alla volta , con occasionali reset a zeroquando appropriato. Cosa c'è di sbagliato inciò ? Un bug nel programa potrebbe assegnare un valoreerrato ala variabile, per una qualsiasi ragione imprevista.Choiunque abbia programmato in C sa cosa significa spendereore o giorni cercando di individuare un bug la cui causasembrerà assurdamente semplice una volta individuato.(il momento dell'individuazione del bug ècomunemente indicato come il rumore di un forte schiaffosulla fronte.)

lo stesso problema verrebbe attaccato da un angolo moltodifferente nel caso di contesto orientato agli oggetti. Laprima cosa che un programmatore si chiederebbe nel progettareil contachilometri non sarebbe "quale dei soliti tipi didato assomiglia abbastanza a questa cosa?" ma "comedeve funzionare esattamente questa cosa?". La finisceper essere rilevante. È necessario spendere un po'di tempo per decidere cosa debba fare un contachilometri ecome ci si aspetat che il mondo ci interagisca . Decidiamo dicostruire una macchina con controlli che ci permettano diincrementare, effettuare il reset it, leggere il valore ebasta.

Non forniamo un modo tramite il quale asegnare alcontachilometri valori arbitrari; perchè?Perchè sappiamo tutti che i contachilometri nonfunzionano così. Ci sono solo poche cose che dovrestepoter fare con un contachilometri, e quelle sono le sole coseche permettiamo. Inoltre, se qualcosa nel programmaincidentalmente cercasse di mettere qualche altro valore (adesempio, la temperatura impostat nel climatizatore delveicolo) nel contachilometri, ci sarebbe un'indicazioneimmediata di cosa fosse andato male. Ci verrebe fatto notareall'esecuzione del programma (o magari al momento dellacompilazione, dipendentemente dalla natura del linguaggio )che non ci è permesso assegnare valori arbitrariagli oggetti Contachilometri. Il messaggio potrebbe nonessere proprio così chiaro , ma saràragionevolmente simile. Ciò mnon previenel'errore, vero? Ma ci indirizza subito verso la cuasa.Questo è solo uno dei modi in cui la programmazione OOpuò risparmiarci un sacco di tempo sprecato.

Spesso effettuiamo un ulteriore passo di astrazione oltrequesto,perchè realizzare una fabbrica che facciamacchine risulta semplice come costruire la macchina stessa.Non è probabile che costruiremo un contachilometrisingolo direttamente; piuttosto, facciamo si che un numeroqualunque di contachilometri possa essere fabbricato comn unsingolo processo. Il processo(o se preferite, la fabbrica dicointachilometri) corrisponde a quella che chiamiamo unaclasse, ed un contachilometri individuale generatodal processo (o dalla fabbrica) corrisponde ad unoggetto. La maggior parte dei linguaggi OO richiedeche sia definita una classe prima di avere un nuovo tipo dioggetto, ma ruby non ne ha bisogno.

È importante notare che l'uso di un linguaggio adoggetti non forza un designo OO corretto. Infattiè possibile scrivere codice in ogni linguaggio che siapoco chiaro, confuso, mal pensato, pieno di bug, pieno dilacune. Ciò che viene fatto da ruby per voi (adifferenza, ad esempio, del C++) è far si che lapratica della programmazione ad oggetti risulti abbastanzanaturale da far si che anche quando state lavorando supiccola scala non abbiate la necessità di rrivolgervia codice orribile per risparmiare fatica. Discuteremo deimetodi in cui ruby raggiunge questo ammirevole scopo man manoche questa guid ava avanti; il prossimo argomento sarà"bottoni e quadranti" (metodi degli oggetti) e poipasseremo alle “fabbriche” (classi). Ci sieteancora?



Ti potrebbe interessare anche

commenta la notizia