Commenti & Opinioni

...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 -- Lisa

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

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

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

> 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

>> 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

> >> 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

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

-- Eremita Solitario

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

> A loro basta copiare da progetti già fatti

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

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

> 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

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

> 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

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

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

> 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

> > 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

> > > 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

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