Commenti & Opinioni


Home Page | Commenti | Articoli | Faq | Documenti | Ricerca | Archivio | Storie dalla Sala Macchine | Contribuire | Login/Register

L'Oggetto del Desiderio

No, non sto' parlando della mia moto, ne' di ... avete capito... Sto' parlando di programmazione object-oriented. Quella cosa che una decina di anni fa' pareva fosse l'ultimissima moda e venuta direttamente dalle mani del Buddha per salvare l'umanita' e che poi ha perso parecchio del suo carisma.

Il motivo dell'odierno pistolotto e' che nel corso della settimana vi sono state discussioni varie in ufficio al riguardo e quindi ho pensato bene di mettere per iscritto le mie opinioni al riguardo in modo che la prossima volta potro' limitarmi a puntare tutti verso questo documento e risparmiarmi la fatica.

Alura, "Object Oriented" si riferisce alla tecnica (alcuni parlano di "paradigmi") usata per creare "oggetti", che altro non sono che blocchi di codice che sono poi usati all'interno del programma. Niente di anormale. L'idea di mettere parti di codice che sono usate e riusate in 'funzioni' o 'subroutine' e' arcinota ed e' usata fin dai tempi del Basic (allora si usavano Gosub e Goto).

Ma mentre in un programma "normale" le funzioni e subroutine ed i dati che tali funzioni e subroutine manipolano sono altrettanto visibili e manipolabili, la OOP fa' un passo in piu' e trasforma le subroutines ed i loro dati associati in delle "scatole nere" impenetrabili. Tutto quello che sappiano di tali 'scatole' e' che hanno delle interfaccie (quali pulsanti e leve possiamo operare) che ci permettono di controllarle, ficcare dentro i nostri dati ed ottenerne i risultati.

Questo consente una certa indipendenza dal come un certo oggetto e' costruito. Fintanto che l'oggetto presenta la stessa 'interfaccia', non ci interessa che cosa fa' "dentro" ne' come lo fa'. L'unica cosa che ci interessa sapere e' come usarlo. Cambiare l'implementazione di un oggetto non rischia di crashare l'intero programma finche' il nuovo oggetto presenta la stessa interfaccia al resto del programma.

Ora, la discussione scatenata in ufficio e' se la OOP sia una cosa positiva, negativa o neutrale. Cioe' se sia una buona cosa usarla o se sia semplicemente una complicazione inutile o che non faccia alcuna differenza.

La mia opinione sull'argomento e' dipende.

Da mio punto di vista (punto di vista maturato in 25 anni di sviluppo software dall'amatoriale al professionale con gruppi di sviluppo che andavano da "io" a 25+ programmatori divisi in 3 palazzi), il principale vantaggio che ha la OOP rispetto ad altre tecniche e' l'isolamento che offre tra i vari "pezzi" del programma che si sta' scrivendo e la capacita' di prendere uno di questi pezzi e riutilizzarlo da qualche altra parte senza preoccuparsi troppo di come fa' le cose ma solo di cosa fa'.

Del codice robusto si puo' scrivere solo se si hanno le idee ben chiare su cosa fa' ogni singola parte di codice e come lo fa'. Il che e' molto facile (o comunque possibile) se chi sviluppa software e' una sola persona (perche' allora e' tutto nella sua testa) o se sono un numero limitato e si appoggiano su una documentazione e specifiche di progetto che sono ben definite e note a tutti. Quindi codice anche vasto, ma ben noto e senza "conigli" che saltano fuori dal cappello ad ogni momento.

Il problema e' quando il progetto comincia ad essere distribuito su piu' persone che non "collaborano" perche' stanno facendo altro o non sono sempre presenti nello stesso posto. E soprattutto quando chi dovrebbe coordinarne l'attivita' (il "project manager" di turno) non ha la piu' pallida idea di come sviluppare software o di cosa voglia dire 'coordinare'. In questo caso la OOP puo' aiutare, ma non e' detto che sia risolutiva.

Il vantaggio della OOP e' che ogni oggetto e' (come detto prima) una scatola nera, quindi molto meno suscettibile a cambiamenti nel 'resto' del programma. Un programmatore puo' a questo punto concentrarsi nello sviluppo di un singolo componente che faccia un certo lavoro, ed un altro programmatore (magari in un palazzo diverso) potra' prendere quel componente ed usarlo direttamente senza doversi preoccupare di come fa' il suo lavoro "sotto al coperchio". Ed i componenti di entrambi potranno interagire con altri pezzi nello stesso modo, riducendo la necessita' di lunghe e barbose riunioni per definire come perche' viene fatto qualche cosa. Questo se l'interfaccia di ogni oggetto e' ben specificata. Ma quel "se" e' un "se" bello grosso.

In un progetto in cui mi capito' di lavorare, il manglement si era buttato sulla OOP come un lupo famelico su un agnello bello grasso, ma nella loro foga oggettivistica si erano dimenticati di una cosa: le specifiche devono esserci lo stesso. Il risultato e' stato un ovvio disastro in cui una caterva di oggetti venivano sviluppati da tutti ma nessuno di questi riusciva ad interfacciarsi con nessun altro perche' nessuno aveva la piu' pallida idea di come fare.

Quindi, OOP bene o male? La risposta e' (come sempre) dipende....

Dipende dalla dimensione del progetto e dalla qualita' e dal numero dei programmatori che vi sono addetti, dipende dalla qualita' e capacita' del Project Manager in carico, dipende dalla qualita' delle specifiche, dipende da quanto di quel progetto sia in programma per "riciclo" in altri progetti ed ovviamente dipende dall'ambiente prescelto per lo sviluppo (sviluppare in non-OOP in Java e' un po' dura eh).

Certo, mettersi a scrivere un software usando OOP puo' richiedere molto piu' tempo che scrivere lo stesso programma senza OOP. E spesso e' cosi'. Ed infatti la mia opinione e' che la OOP e' piu' adatta a progetti da una certa dimensione in su'. Se devo scrivere un programmino per analizzare dei file di log, vado di bash o perl, di certo non mi metto a scrivere una applicazione in Java o in C++ per fare la stessa cosa, se devo sviluppare un filtro milter invece, molto probabilmente usero' il C. Ma se il progetto richiede diverse settimane (e non e' una roba da fare nel week-end), e ci sono ottime probabilita' che una cosa simile sia da rifare per qualcun altro, allora posso cominciare a tenere in considerazione C++ ed eventualmente Java.

E chi dice che OOP e' auto-documentante dovrebbe bere un po' di vernice e ritirarsi dalla vita! La documentazione del codice e del progetto e' sempre un punto essenziale, documentazione insufficiente o totalmente mancante e' uno dei casi principali di fallimento di un progetto. Insieme a Project Manager che non sanno cosa ca$$o stanno facendo o perche', ma sto' divagando. Quando un programmatore se ne va' o viene sostituito bisogna potergli dare della documentazione da studiare per permettergli di capire che accidenti sta' succedendo e come, leggere il codice aiuta, ma non e' la soluzione migliore.

Davide Bianchi
08/12/2009 15:04

 

I commenti sono aggiunti quando e soprattutto se ho il tempo di guardarli e dopo aver eliminato le cagate, spam, tentativi di phishing et similia. Quindi non trattenete il respiro.

20 messaggi this document does not accept new posts
Lisacome tutte le cose... Di Lisa - postato il 06/12/2009 12:42
...hai ragione te, dipende!

"Gli oggetti sono una bella cosa" (frase su cui sono perfettamente d'accordo) non deve però trasformarsi in "li butto ovunque senza pensarci su cosė fa figo ed è bello". Se il programmatore già di suo è capra e non ha la più pallida idea di come si mette su una buona struttura, non saranno certo gli oggetti a trasformare una ciofeca in una meraviglia della tecnologia informatica :D

--
Lisa


Luca MenegottoCondivido tutto! Di Luca Menegotto - postato il 06/12/2009 18:42

E aggiungo: nella mia esperienza, con la OOP la fase progettuale diventa molto più importante. Prima di iniziare a pestare tasti, bisogna pensare, pensare e poi ancora pensare, e infine scrivere (documentazione, non codice!), che spesso ci si rende conto che si era pensato male e si deve tornare indietro.
E' un esercizio difficile, la OOP, che richiede inizialmente molto più tempo che non qualsiasi altro tipo di programmazione (ecco perché condivido quando tu parli di progetti grossi). Però poi consente livelli di manutenibilità impensabili in altro modo, e evita cose come quella aggiornata la settimana scorsa: codice che, per fare un'operazione, deve essere toccato in tre sorgenti differenti, più un quarto per le variabili di deposito - chi aveva curato la prima stesura era decisamente creativo - .
Ah, dimenticavo. Io uso comunque la OOP in progetti medio-grossi, anche se faccio tutto io. In fondo, non si può pretendere che un povero cristo si ricordi cosa aveva fatto sei mesi prima...

--
Luca Menegotto


Anonymous cowardNon č che gli oggetti fanno il lavoro al tuo posto ... Di Anonymous coward - postato il 06/12/2009 19:05

Non è che se programmi alla ca$$o gli oggetti ti migliorino la vita ma non lo fa neanche la programmazione classica.
Se poi si eviterebbe di fare come qualche collega che mette delle variabili globali nel terzo o quarto livello di include e non li documenta
Purtroppo i project manager che non sanno cosa stanno facendo sono la regola, almeno in Italia.

--
Anonymous coward


MattiaOOP e librerie Di Mattia - postato il 07/12/2009 09:26

Nell'automazione industriale (il campo in cui io lavoro) la programmazione ad oggetti e' sempre esistita, quale componente FONDAMENTALE, poiche' il riutilizzo di parti di codice e' indispesabile sia per ragioni di spazio sia perche' molto spesso una certa "manovra" chi se la ricorda dopo un anno?
Era quindi sufficiente fare il nostro "blocco funzione" (oggetto), ficcarlo dentro ad una "libreria", e ripigliarlo quando ci serve.
Posso dire una cosa? tutta 'sta fregola per un'innovazione che nuova non e', ha solo un nome diverso.
Gosub e Goto... sai che alcuni sistemi di motion control si programmano ancora oggi in basic?

--
Mattia


Davide Bianchi@ Mattia Di Davide Bianchi - postato il 07/12/2009 09:29

> Gosub e Goto... sai che alcuni sistemi di motion control si programmano ancora oggi in basic?

Io conosco sistemi che sono tutt'ora programmati in Cobol...

--
Davide Bianchi


sky@ Davide Bianchi Di sky - postato il 07/12/2009 11:29

>> Gosub e Goto... sai che alcuni sistemi di motion control si programmano ancora oggi in basic?
> Io conosco sistemi che sono tutt'ora programmati in Cobol...

In ambito bancario (dove lavoro io) è cosė ancora per la _maggior_parte_ della programmazione. D'altro canto si lavora su sistemi transazionali che, per questioni economiche, hanno librerie "consolidate" (non "vecchie" ;\)) da decenni e sottosistemi ancora più "testati" (non "obsoleti") come IMS (già CICS è più nuovo).
Non solo: per tante cose DB2 è ancora una novità, mentre tanti software ancora lavorano su archivi VSAM (gerarchici veramente antichi) ed il "file sequenziale" è spesso la norma, anche se supportato da sistemi operativi "decentemente aggiornati", sempre relativamente al settore, che punta più alla stabilità che all'innovazione... d'altro canto preferiresti anche tu evitare di vedere troppe virgole spostate nel senso sbagliato no? ;\)

--
sky


Dr_Halo@ sky Di Dr_Halo - postato il 07/12/2009 12:37

> >> Gosub e Goto... sai che alcuni sistemi di motion control si programmano ancora oggi in basic?
> > Io conosco sistemi che sono tutt'ora programmati in Cobol...
>
> In ambito bancario (dove lavoro io) è cosė ancora per la _maggior_parte_ della programmazione. D'altro canto si lavora su sistemi transazionali che, per questioni economiche, hanno librerie "consolidate" (non "vecchie" ;\)) da decenni e sottosistemi ancora più "testati" (non "obsoleti") come IMS (già CICS è più nuovo).
Anche io lavoro in ambito bancario, e posso dire che la maggior parte del software rimane sviluppata in Cobol per problemi di performance piu' che per mancanza di affidabilita', consolidamento ed impossibilita' di innovazione.

--
Dr_Halo


Eremita SolitarioCondivido appieno... Di Eremita Solitario - postato il 07/12/2009 11:17

... e ti dico di più, credo che usero queste tue parole in azienda. Posso stampare e distribuire questo testo ai colleghi vero?

--
Eremita Solitario


ataru1976Mitico! Di ataru1976 - postato il 07/12/2009 16:04

Non posso che essere completamente d'accordo con questo articolo.
Ricalca fedelmente il mio pensiero, tanto che in alcuni punti mi sono chiesto se non l'avessi scritto io!
Il vero problema, che più volte è stato affrontato anche qui, è che buona parte dei programmatori odierni non ha la più pallida idea di cosa voglia dire programmare. A loro basta copiare da progetti già fatti o, nei casi peggiori, chiedere nei forum.
Spero che le cose possano cambiare presto, perché questa superficialità genera molta diffidenza nei clienti.

--
ataru1976


maxxfi@ ataru1976 Di maxxfi - postato il 08/12/2009 15:33

> A loro basta copiare da progetti già fatti

Questa è la loro interpretazione dell'importante concetto di "riusabilità del software" :-D

--
maxxfi


CymonUtopia Di Cymon - postato il 08/12/2009 12:26

Concordo su tutto, ma la premessa di avere a disposizione buona documentazione è, ahimè, molto spesso utopistica. Da questo punto di vista la programmazione a oggetti aiuta perché permette appunto di concentrarsi su una parte della documentazione (le interfacce) e dimenticare tutto il resto, che diventa una questione tra lo sviluppatore e la sua coscienza. In questo è stato un gran passo avanti.
Un aiuto al paradigma è venuto anche dal fatto che oggi come oggi la maggior parte dei linguaggi di progettazione o modalità di scrittura della stessa si sono orientati a oggetti a priori rendendo immediato tradurre le cose in questo modo, ma anche praticamente impossibile fare altrimenti.

Poi, quello che dico sempre io è che non esiste tecnica di programmazione (nemmeno le più avanzate come la XP e tutto il resto) che sia a prova di cretino. Un programmatore intelligente farà buon codice, un programmatore stupido farà disastri. Nunc et semper. E incredibilmente non tutti ne sono convinti.

--
Cymon


Riccardo Cagnasso@ Cymon Di Riccardo Cagnasso - postato il 08/12/2009 15:14

> Concordo su tutto, ma la premessa di avere a disposizione buona documentazione è, ahimè, molto spesso utopistica. Da questo punto di vista la programmazione a oggetti aiuta perché permette appunto di concentrarsi su una parte della documentazione (le interfacce) e dimenticare tutto il resto, che diventa una questione tra lo sviluppatore e la sua coscienza. In questo è stato un gran passo avanti.

Questo avrebbe senso solo se l'implementazione fosse perfetta, bugfree e non dovesse mai piu' essere toccata... BWHAWHAWHAWHAWHAWHAW


> Poi, quello che dico sempre io è che non esiste tecnica di programmazione (nemmeno le più avanzate come la XP e tutto il resto) che sia a prova di cretino.

Si ma qui' l'approccio e' al contrario. Piu' "avanzata" una tecnica di programmazione e', piu' in gamba deve essere il programmatore che la mette in atto e solo a quel punto migliore e' il risultato. Per esempio probabilmente una delle tecniche piu' efficaci sarebbe LOP (language oriented programming) ma un programmatore su un milione e' in grado di lavorare in quel modo probabilmente.

Infatto quando fanno XP (a modo loro peraltro) a Oracle, migliorano la produttivita', quando cerca di farlo $wannanbeprogrammatore che gia' fa schifo a programmare normalmente, i risultati son solo peggiori.

--
Riccardo Cagnasso


DrSlumpOOP for dummies Di DrSlump - postato il 08/12/2009 15:56

Io non ho mai programmato seriamente (vaghe riminiscenze di Basic, Fortran e Pascal alle superiori, poche righe di C all'università), e mi sono sempre chiesto che cacchio fossero questi "oggetti", me li sono fatti spiegare un paio di volte ma niente... finalmente 3 semplici paragrafi di Davide mi hanno fatto vedere la luce. Grazie!

--
DrSlump


Maxvecchio problema Di Max - postato il 09/12/2009 00:14

> OOP bene o male? La risposta e' (come sempre) dipende...

Assolutamente d'accordo. Secondo me OOP da` il meglio di se` quando nel gruppo di sviluppo ci sono degli analisti capaci. E magari (visto che alla fine deve decidere lui) un project manager che conosce anche l'uso dei pattern.

Per il resto penso che l'efficacia di qualunque tecnologia di programmazione dipenda principalmente dalla testa (forma mentis e formazione) dei programmatori, ancora piu` che dal problema o dal linguaggio usato.

--
Max


Guidocome tutto del resto Di Guido - postato il 09/12/2009 08:12

Non solo la programmazione Object Oriented (o Obje-Oriendete come diceva un mio professore universitario) ma tutta la programmazione in generale se fatta con cervello e idee chiare è una cosa, se fatta con il cu... e con sorprese che saltano fuori ad ogni angolo è un'altra...

--
Guido


ringoPerche' i PM non sanno mai un ca$$o del progetto... Di ringo - postato il 09/12/2009 09:54

Adesso vi racconto quello che mi e' capitato poco tempo fa (e che dura tuttora).
Un PM mi incarica di scrivere qualche procedura che deve girare in un batch schedulato: "Tu che sei bravo con i batch e conosci il perl..."

Io apro il mio editor e comincio a scrivere queste cosette che fotografano il sistema, controllano lo stato dei processi, lo spazio su disco, etc etc...
Scrivono tutto in un log...
Poi un'altra procedura analizza il log, ed al verificarsi di determinate condizioni scrive dei files nelle directory di spool per le mail e per gli sms.
Infine un'ultima procedura se trova roba negli spool, manda mail e sms di allarme.
Cosette abbastanza banali, tanto che non mi sono neanche chiesto il perche' e il percome, le ho fatte e basta.

Le consegno, e il PM mi fa: "Bravo, adesso siccome io ho altro da fare, puoi occuparti tu di completare il progetto!"

E io che mi sono ritrovato promosso sul campo a capo progetto, di un progetto di cui nulla so, ho sentenziato: "Adesso capisco perche' i PM non sanno mai un ca$$o del progetto di cui si occupano!"


--
ringo


Davide Bianchi@ ringo Di Davide Bianchi - postato il 09/12/2009 11:29

> Cosette abbastanza banali, tanto che non mi sono neanche chiesto il perche' e il percome, le ho fatte e basta.
...
> E io che mi sono ritrovato promosso sul campo a capo progetto, di un progetto di cui nulla so,

Ti faccio notare che se non ne sai nulla e' perche' non hai chiesto, non perche' non ti sono state date le informazioni ma perche' non te ne sei interessato. Quindi tu stai dicendo che i PM in genere non sanno un ca$$o perche' passano il tempo sbattendosene?

--
Davide Bianchi


ringo@ Davide Bianchi Di ringo - postato il 10/12/2009 09:32

> > Cosette abbastanza banali, tanto che non mi sono neanche chiesto il perche' e il percome, le ho fatte e basta.
> ...
> > E io che mi sono ritrovato promosso sul campo a capo progetto, di un progetto di cui nulla so,
>
> Ti faccio notare che se non ne sai nulla e' perche' non hai chiesto,

Quale parte di "...siccome io ho altro da fare..." non ti e' chiara?
(Oddio, non ci posso credere, lo sto dicendo a D.B.!!!)

> non perche' non ti sono state date le informazioni ma perche' non te ne sei interessato. Quindi tu stai dicendo che i PM in genere non sanno un ca$$o perche' passano il tempo sbattendosene?

Sto dicendo che i PM in generale non sanno un ca$$o perche' in generale non esiste un progetto definito ma un barile che viene scaricato.
Il PM precedente non sa, non puo', non vuole passarmi informazioni, che probabilmente non ci sono, che probabilmente pure lui aveva questo barile capitatogli per caso per le mani prima di me.
A chi chiedo io? Se ci fosse qualche fottuto manuale da leggere, lo avrei anche letto, ma non c'e'. :-\(

--
ringo


Davide Bianchi@ ringo Di Davide Bianchi - postato il 10/12/2009 09:58

> > > E io che mi sono ritrovato promosso sul campo a capo progetto, di un progetto di cui nulla so,
> >
> > Ti faccio notare che se non ne sai nulla e' perche' non hai chiesto,
>
> Quale parte di "...siccome io ho altro da fare..." non ti e' chiara?
> (Oddio, non ci posso credere, lo sto dicendo a D.B.!!!)

Era chiarissima, ma quando una cosa simile successe a me , mi sedetti, staccai il cavo del monitor del supposto project lader e gli feci il terzo grado per sapere il come, il cosa e soprattutto il perche' del progetto. E misi bene in chiaro con lui e con il di lui capo che o mi davano tutte le informazioni richieste o il progetto se lo potevano ficcare dove non batte mai il sole.

> Sto dicendo che i PM in generale non sanno un ca$$o perche' in generale non esiste un progetto definito ma un barile che viene scaricato.

E di nuovo, se il barile me lo vuoi scaricare io lo posso anche accettare, ma per accettarlo voglio avere le informazioni per poter fare il mio lavoro. Altrimenti te lo infili su' per il didietro.

> A chi chiedo io?

A chi il progetto lo dovrebbe usare? Questa e' la filosofia internettiana, io butto li' una palla e qualcuno la prendera', non mi viene in mente di sbattermi per trovare le informazioni, tanto non e' lavoro mio no?

--
Davide Bianchi


lucasterCondivido, ma parzialmente Di lucaster - postato il 14/12/2009 11:28

Fino a che si tratta di qualcosa che faccio da solo (sia esso per lavoro o personale), posso anche valutare come superfluo l'overhead richiesto dalla OOP e usare linguaggi di scripting o ricadere sul fidato C.

Ma se devo fare qualcosa di riusabile o (peggio) con altri, a meno di strani vincoli, ritengo l'OOP la scelta sempre migliore: se ci si butta sull'implementazione troppo presto si fanno danni sempre e comunque; un'interfaccia sviluppata con troppi (o troppo pochi) metodi / parametri / etc non la vedo molto diversa da una libreria fatta in C con problemi simili.

Il vantaggio, a mio parere, e' che la definizione di "oggetto" e' (nella maggior parte dei casi) chiara e la possibilita' di definire cambiare in maniera "indolore" due implementazioni della stessa classe (a parita' di interfaccia) aiuta il lavoro in un team.

Inoltre, se ho definito correttamente le specifiche, e' piu' facile cambiare l'implementazione di un metodo in una classe che una funzione di libreria; se ho definito male le specifiche... il problema e' indipendente dall'implementazione

--
lucaster


20 messaggi this document does not accept new posts

Precedente Successivo


Il presente sito e' frutto del sudore della mia fronte (e delle mie dita), se siete interessati a ripubblicare uno degli articoli, documenti o qualunque altra cosa presente in questo sito per cortesia datemene comunicazione (o all'autore dell'articolo se non sono io), cosi' il giorno che faccio delle aggiunte potro' avvisarvi e magari mandarvi il testo aggiornato.


Questo sito era composto con VIM, ora e' composto con VIM ed il famosissimo CMS FdT.

Questo sito non e' ottimizzato per la visione con nessun browser particolare, ne' richiede l'uso di font particolari o risoluzioni speciali. Siete liberi di vederlo come vi pare e piace, o come disse qualcuno: "Finalmente uno dei POCHI siti che ancora funzionano con IE5 dentro Windows 3.1".

Web Interoperability Pleadge Support This Project
Powered By Gort