Comments & Opinions


Home Page | Comments | Articles | Faq | Documents | Search | Archive | Tales from the Machine Room | Contribute | Set language to:en it | Login/Register


The Object of Desire

No, I'm not talkign about my motorbike, neither of ... you know what... I'm talking about Object-Oriented-Programming. That thing that a dozen or so years ago was the latest fad came down directly from the hands of Buddha to save the humanity and then lost a lot of steam.

The reason for today burst is that during the week I had a series of discussions at the office about oop, so I decided to put this stuff in writing so in the future I'll simply refer peoples to this page instead of repeating the whole thing.

Object Oriented is referred to the technique (some speak about 'paradigm') used to build 'objects' that are nothing more than blocks of data and codes inside the computer's memory, that are then used by the application. Nothing fancy, the idea of having codes into functions or subroutines and then call them from other parts of the program is well known and was used since the beginning of software development.

But while in a 'normal' program functions and subroutines and their data are open to view and use by everyone, OOP goes the extra step of locking them into "black boxes" that can only be manipulated through a specific 'interface'. All we know and need to know about those boxes is the way to interact with them.

This allow a mesure of independency between the what a specific object does and the how it does it. As long as the interface stays consistent, the object can be replaced with another one without any other changes in the code.

Now, the discussion at the office mostly hinged if OOP is positive, negative or neutral. That is, if it is a good thing to use, if it is a useless complication or if it doesn't make any difference.

My opinion? it depends.

From my point of view (maturated in 25 years of software development, from amatorial to professional with development groups ranging from 'me' to 25+ developers distributed in many buildings), the great advantages of OOP if confronted with other systems is the insulations that it offers between the various 'parts' of an application and the ability to take one of the piece and use it somewhere else without too many problems about how it does its job.

You can write robust code only if you have a clear idea about what each part of an application does and how it does it. That is easy (or possible) if the code is developed by just one person (because the whole code should fit in his brain) or if there is a limited number of developers and they are using a well maintained and well known documentation and project specification. So even a lot of code but without surprises that jump out unexpectedly.

The problem arise when the project begin to be so huge that have to be distributed between multiple developers that are unable to cooperate because they are doing other things or they are not always available. And especially when whomever should coordinate the job (the "project manager") doesn't have a fscking clue about how to develop the software and what 'coordinate' means). In this case OOP can help, but ain't a silver bullet.

The advantage of OOP is that each object is (as said before) a black box, so is not that sensitive of changes in the environment. A developer can concentrate into building single components to perform a specific job and another developer can use them in another part of the software without too many trouble. This works fine if the interface is well defined. But this is a huge 'if'.

In a project I worked for a while the manglment had jumped into the OOP stuff with both feet at once, but in their haste they forgot one thing: you need to specify the interface first. The result was a disaster with lots of object created but nobody could use them because there was no clear way to use them.

So, OOP is good or bad? It depends...

It depends by the size of the project and the number and quality of the developers involved. It depends by the quality and capacity of the project manager involved. By the quality of the specification and analysis and (last but not least) by how much of the code is erarmarked for 'reuse' in other projects. And of course it depends by the environment chosen for the development (not doing OOP in Java is a bit difficult).

Sure, writing an application using OOP can (and mostly does) take more time and effort than using non-OOP. My opinion is that OOP is best suited for medium-to-large projects. If I have to write a procedure to analyze a bunch of log files I'll use bash or perl, if speed is required probably C. Certainly I'm not going to use Java o C++. But if the project requires several weeks and there are a lot of possibilities that parts of it will be recycled, I can consider C++ or Java.

And whoever says that OOP is self-documenting should drink some paint and retire from life! Project and code documentation are essential. Lack of documentation is one of the common case for a failure. That and a project manager that doesn't know what he is doing and why.

Davide Bianchi
08/12/2009 15:04

Comments are added when and more important if I have the time to review them and after removing Spam, Crap, Phishing and the like. So don't hold your breath. And if your comment doesn't appear, is probably becuase it wasn't worth it.

20 messages this document does not accept new posts

Lisa

come tutte le cose... By Lisa posted 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 Menegotto

Condivido tutto! By Luca Menegotto posted 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 coward

Non č che gli oggetti fanno il lavoro al tuo posto ... By Anonymous coward posted 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

Mattia

OOP e librerie By Mattia posted 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 By Davide Bianchi posted 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 By sky posted 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 By Dr_Halo posted 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 Solitario

Condivido appieno... By Eremita Solitario posted 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

ataru1976

Mitico! By ataru1976 posted 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 By maxxfi posted 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

Cymon

Utopia By Cymon posted 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 By Riccardo Cagnasso posted 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

DrSlump

OOP for dummies By DrSlump posted 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

Max

vecchio problema By Max posted 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

Guido

come tutto del resto By Guido posted 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

ringo

Perche' i PM non sanno mai un ca$$o del progetto... By ringo posted 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 By Davide Bianchi posted 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 By ringo posted 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 By Davide Bianchi posted 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

lucaster

Condivido, ma parzialmente By lucaster posted 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 messages this document does not accept new posts

Previous Next


This site is made by me with blood, sweat and gunpowder, if you want to republish or redistribute any part of it, please drop me (or the author of the article if is not me) a mail.


This site was composed with VIM, now is composed with VIM and the (in)famous CMS FdT.

This site isn't optimized for vision with any specific browser, nor it requires special fonts or resolution.
You're free to see it as you wish.

Web Interoperability Pleadge Support This Project
Powered By Gojira