[Vari] Critica alla programmazione ad oggetti.

javaboy · 11-03-2009, 20:05

Vi propongo un articolo interessante di Joe Armstrong (l'autore del linguaggio funzionale Erlang) che critica aspramente la programmazione ad oggetti.
http://www.sics.se/~joe/bluetail/vol1/v1_oo.html

Che ne pensate?

cdimauro · 11-03-2009, 20:43

Vabbé, ma che t'aspettavi da uno che ha scritto un linguaggio puramente funzionale?

Bullshits.

Tommo · 11-03-2009, 21:00

Quote:

Objects bind functions and data structures together in indivisible units. I think this is a fundamental error since functions and data structures belong in totally different worlds.

Chi diamine lo ha detto?

Quote:

So I can't find all the data type definition in one place.

Si chiama incapsulamento ed è uno dei principali vantaggi dei linguaggi OO.

Quote:

In an OOPL I have to choose some base object in which I will define the ubiquitous data structure

unicamente se non hai capito nulla dell'OO

Quote:

Reason 1 - It was thought to be easy to learn.
Reason 2 - It was thought to make code reuse easier.
Reason 3 - It was hyped.
Reason 4 - It created a new software industry.
I see no evidence of 1 and 2

La 1 e la 2 la vedo ovunque, in qualsiasi SDK mi sia stato dato usare. Non solo, la 2 con l'OOP ha una cifra di nuove possibilità.

In finale mi sembra il rant di uno che l'OO non ha manco capito da che parte si guarda, e fortuna che ha scritto un linguaggio.

VICIUS · 11-03-2009, 22:12

Deve essere un po' frustrato perché dopo venti anni di sviluppo il suo linguaggio non ha ancora avuto il successo che sperava mentre la programmazione ad oggetti ha semplicemente conquistato tutti.

~FullSyst3m~ · 11-03-2009, 22:40

Ma la domanda è: in quale secolo ha iniziato a scrivere questo linguaggio?

Ecco i traumi che ti segnano per tutta la vita. Stai chiuso in una cantina a pane e acqua a programmare per due secoli, e quando esci scopri che c'è una cosa chiamata OO e non potendola uccidere se la prende con chiunque abbia anche una sola O nel proprio nome

VICIUS · 11-03-2009, 22:48

Quote:

Originariamente inviato da ~FullSyst3m~

Ma la domanda è: in quale secolo ha iniziato a scrivere questo linguaggio?

Fine ani ottanta. Quindi tecnicamente ha cominciato lo scorso millennio

~FullSyst3m~ · 11-03-2009, 22:55

Quote:

Originariamente inviato da VICIUS

Fine ani ottanta. Quindi tecnicamente ha cominciato lo scorso millennio

javaboy · 11-03-2009, 23:02

Non sono d'accordo con quando ha scritto Armstrong anche se penso che i linguaggi funzionali meriterebbero maggior spazio.
Erlang in particolare sembra molto interessante sopratutto per la programmazione concorrente.
Facebook per la sua chat ha utilizzato appunto erlang e sono stati effettuati dei test in cui Yaws (web server scritto in erlang) ha surclassato apache.
http://www.sics.se/~joe/apachevsyaws.html

Ci sono anche dei framework per il web in erlang:
http://erlyweb.org/

cionci · 11-03-2009, 23:17

Riguardo all'ultimo link: non dimostra certo che un linguaggio funzionale è migliore degli altri...al massimo dimostra che yaws sotto questo aspetto è migliore di Apache.
Magari quel test è stato creato appositamente per mettere in difficoltà Apache...è un po' strano come test...la richiesta GET viene inviata un carattere al secondo...quando mai succede ? Al massimo è un attacco DOS per Apache.

javaboy · 11-03-2009, 23:43

Quote:

Originariamente inviato da cionci

Riguardo all'ultimo link: non dimostra certo che un linguaggio funzionale è migliore degli altri...al massimo dimostra che yaws sotto questo aspetto è migliore di Apache.
Magari quel test è stato creato appositamente per mettere in difficoltà Apache...è un po' strano come test...la richiesta GET viene inviata un carattere al secondo...quando mai succede ? Al massimo è un attacco DOS per Apache.

Sono d'accordo sul fatto che il test sia un pò strano ma penso che l'ottimo risultato di yaws sia dovuto al modello di gestione dei processi di Erlang, non a YAWS.
Ecco qualche articolo interessante:
http://queue.acm.org/detail.cfm?id=1454463
http://gigaom.com/2007/12/19/erlang-...-20-years-old/

cionci · 11-03-2009, 23:49

Ma facciamo un test di carico serio e vediamo se la differenza sta ancora in questi termini, andando a vedere il tempo medio di esecuzione delle richieste.

Sicuramente l'unica cosa che suggerisce quel test è un modo per fare un DDoS ad Apache

javaboy · 11-03-2009, 23:57

Quote:

Originariamente inviato da cionci

Ma facciamo un test di carico serio e vediamo se la differenza sta ancora in questi termini, andando a vedere il tempo medio di esecuzione delle richieste.

Non c'è bisogno di farlo! Sappiamo entrambi la risposta.

Ciò non toglie che Erlang sia interessante sotto alcuni aspetti.

Ecco cosa ne pensano gli sviluppatori di facebook:
http://www.facebook.com/notes.php?id=9445547199

The channel servers are the most intricate piece of the backend. They're responsible for queuing a given user's messages and pushing them to their web browser via HTTP. We made an early decision to write the channel servers in Erlang. The language itself has many pros and cons, but we chose Erlang to power Chat because its model lends itself well to concurrent, distributed, and robust programming. It's easy to model our millions of concurrent users with a few lightweight processes each, where the same tactic in, say, C++ would have been more daunting. Programming languages are always a tradeoff; Erlang makes some hard things easy but, unfortunately, some easy things hard.

sottovento · 12-03-2009, 05:47

Quote:

Originariamente inviato da javaboy

Vi propongo un articolo interessante di Joe Armstrong (l'autore del linguaggio funzionale Erlang) che critica aspramente la programmazione ad oggetti.
http://www.sics.se/~joe/bluetail/vol1/v1_oo.html

Che ne pensate?

Ne penso bene, mi trovo fondamentalmente d'accordo. E' forse un po' tiepido.

Penso che attualmente la programmazione ad oggetti sia ultra utilizzata (spesso a sproposito) e che sia ritenuta il non-plus-ultra. Non sono cosi' intelligente per poter fornire un'alternativa, ma sono sicuro che un'alternativa migliore esista. E se non esiste, i tempi sono maturi per trovarla.

D'altronde, la scienza (anche l'informatica) e' sempre progredita mettendo in discussione (spesso asserendo addirittura il contrario) i principi che venivano ritenuti assodati, no?

Forse l'articolo riporta troppo poche motivazioni. E' facile trovare altre motivazioni sul fatto che la programmazione ad oggetti abbia dei limiti e che sia ora di trovare qualcosa di meglio:

1 - result = sin(a) * b + c;
result = Math.Add (Math.Times (Math.Trig.sin(a), b), c);
Quale dei due e' piu' semplice? (NOTA - So benissimo che in C++/Java/... posso scrivere entrambe, e' un esempio per rendere l'idea). Quale delle due e' da considerarsi object-oriented?

2 - In questo forum vengono molto frequentemente postati dei messaggi di persone che vogliono imparare a programmare.
Sintetizzando, le risposte sono del tipo: "Impara a programmare con le procedure e poi passa alle classi".
Perche'? Sempre nelle stesse risposte si dice che la programmazione ad oggetti e' piu' naturale! Allora, perche' non si parte ad imparare le basi della programmazione ad oggetti, lasciando per ultima la programmazione piu' difficile?

3 - Quando si usano i linguaggi ad oggetti, si tende a modellare tutto con classi, cioe' "proprieta'" e "metodi" o "messaggi". Questo e' piu' naturale?
Per esempio:

Bicchiere bicchiere;
bicchiere.riempi (acqua);

Cosa c'e' di naturale di un bicchiere che si auto-riempie di acqua? NOTA - non e' un esempio forzato, succede tantissime volte in tutti i software che mi e' capitato di vedere in 20 anni di programmazione: gli oggetti che subiscono l'azione diventano gli attori della stessa.

Comunque, se si preferisce:
Bicchiere bicchiere;
Acqua acqua;
acqua.riempi (bicchiere);
Sembra piu' naturale? Meno male che l'acqua ha un metodo per riempire il bicchiere

4 - Perche' lo stesso bicchiere deve ereditare dalla classe Oggetti? E dalla classe Vetro? Cosa c'e' di naturale in questo? Perche' mi devo portare dietro dei "Metodi/Messaggi" che non mi serviranno a niente, visto che il mio programma usera' il bicchiere per bere l'acqua?

5 - La OOP funziona bene quando e' chiaro cosa deve FARE la classe. Assume che la classe sia un modello di qualcosa che l'utente della stessa conosce gia', nella realta'.
Per esempio, ho appena trovato una classe (in un software scritto da altri) di questo tipo:

class ModelizePlantWithEdgerWithoutL3System: public ModelizePlantWithEdgerOnDownstream
{
....
};

Ritengo di essere del settore (a cui questo software si riferisce), ma credetemi o meno non so come usare la classe!!
Riassumendo: se scrivi una classe che si chiama complex_number probabilmente tutti riescono ad usarla. Quando le cose diventano piu' complesse, siccome la classe si basa sulla conoscenza personale (del singolo programmatore) utilizzare la classe non e' piu' cosi' immediato.
Questo vale a maggior ragione quando la classe ha uno stato, e che obbliga lo sviluppatore a chiamare i metodi in sequenze ben determinate. Ma gli oggetti hanno per forza uno stato!
Nella azienda dove lavoro, si e' riscontrato che l'inserimento di nuovo personale nei progetti esistenti richiede un tempo di training maggiore di qualche anno fa. Domanda: non si dovevano ridurre, questi tempi?

6 - Sempre per il motivo 5, se non e' chiaro cosa deve fare le classe, l'ereditarieta' non fa altro che peggiorare le cose. E' come se il famoso INCAPSULAMENTO (inteso come dati e algoritmi nella stessa classe, i.e. nello stesso posto) venisse a mancare. In sostanza, non sai piu' dove andare a trovare le cose. Dov'e' il metodo che fa questo? Ed il metodo che fa quello? Apri la classe corrispondente all'oggetto con il metodo bacato, ma non lo trovi! Allora devi "risalire la china" delle ereditarieta', sperando di trovarlo.
Lasciamo ovviamente stare il costrutto friend, perche' ho voglia di piangere.

7 - Quando il software comincia a crescere, hai bisogno di un valido software per la documentazione automatica e la ricerca dei metodi. Purtroppo quando si comincia ad usare PESANTEMENTE il polimorfismo, potresti perdere giorni a cercare qual e' esattamente il metodo che viene eseguito ad una determinata condizione. Sto ovviamente parlando di software di milioni di righe, ma e' pur vero che in programmi con programmazione tradizionale NON perdevo quel tempo per cercare cosa succede, anche se il codice risultante era meno elegante (magari sequenze di switch()).
Con l'arrivo della programmazione ad oggetti, e' arrivata anche una serie di nuovi tool di cui prima non si sentiva l'esigenza. Ora sul muro del laboratorio c'e' un grande poster che descrive il diagramma delle classi, tanto per dare un'idea di cosa succede, ed abbiamo un software da 2000$ (per ogni PC) per tener aggiornato il progetto.
Intendiamoci: e' anche vero che il software e' cresciuto nelle dimensioni. Pero' e' anche vero che per poter avere un'idea di cosa sta succedendo si ha bisogno di altri tool, piu' potenti. Anche il semplice editor ti deve ora mostrare la lista dei metodi disponibili per oggetto, e spesso scrivere un programma significa scandire questa lista, alla ricerca del metodo "giusto" (cioe' che "suona" bene). Purtroppo di metodi che suonano "giusti" ce ne sono sempre 3 o 4...
Domanda: come sarebbe la produttivita' in generale senza questi tool? Per ogni metodo si dovrebbe andare a scorrere la documentazione?

8 - Le eccezioni!!! Basandosi su quanto viene affermato anche in comp.lang.c++.moderated (oppure basta leggere "Exceptional C++" del mitico Herb Sutter), ben pochi programmatori hanno capito fino in fondo cosa significa utilizzare le eccezioni (il sottoscritto si ritiene incluso nella lista degli ignoranti). Gli esempi che riporta sono a dir poco illuminanti.
Scrivere codice SICURO rispetto alle eccezioni e' un'impresa non da poco, nonostante tutti si dichiarino ben preparati nel loro uso.
Inoltre, se pensiamo che erano nate per evitare di mischiare il normale flusso di esecuzione dal flusso di esecuzione degli errori, mi viene quasi da piangere: nel codice che ho potuto vedere in questi anni, questo obiettivo non e' stato mai raggiunto. Altro che naturale!!!
In piu', con le eccezioni si doveva eliminare una volta per tutte il blind faith. Ho bisogno di aggiungere altro?
Forse si: qualcosa sulla propagazione delle eccezioni. Fino a quando deve essere propagata un'eccezione? Qual e' il giusto livello per catturarla in maniera efficiente?
In pratica, nella maggior parte del codice che ho visto:
- non si catturano eccezioni importanti ed il programma termina quando vengono sollevate;
- si catturano subito e si riporta un codice di errore (ORRORE! Non eravamo tutti orientati agli oggetti?)
- si catturano e si tappano con un orrendo catch (...).
E se l'eccezione e' riportata da una libreria che hai acquistato, e che magari e' carente nella documentazione? (quale documentazione riporta le eccezioni, e soprattutto, chi le legge?).
In piu', le eccezioni possono generare un sacco di problemi molto carini. Per esempio, sempre leggendo comp.lang.c++.moderated si puo' scoprire che il seguente codice:

MyObject *vect = new MyObject[100];
-- qui usiamo questo vettore, poi:
delete[] vect;

puo' generare dei memory leak ASSOLUTAMENTE NON ELIMINABILI. Quale istruzione genera il memory leak? Ovviamente delete[] vect!!!!

9 - Qualcuno vocifera che se la parte pubblica di una classe non cambia e si cambia solo la parte privata, basta ricompilare
il sorgente della classe e linkare al resto. BALLE. Non per nulla, si sono disegnate architetture (che, fra l'altro, trovo molto eleganti) come COM anche per ovviare a questo.
Esempio:
MyObject *pObject = new MyObject;
Prova a NON ricompilare questa istruzione nel tuo codice che usa l'oggetto MyObject.
In sostanza: cambi la parte privata? Prego, ricompila anche il tuo codice sorgente esattamente come facevi prima. Ci impieghi ore? Ce ne impiegavi anche prima, no?

10 - Ultima parola sul polimorfismo. Altra arma a doppio taglio, visto che non si puo' usare con i vettori! Chi sa cosa succede usando un vettore di oggetti polimorfici? Nessuno! Per fortuna non e' un errore molto comune nel software che mi e' capitato di vedere.

Disclaimer: ovviamente queste sono opinioni personali (piu' qualche *vera* dimostrazione). Anche l'autore dell'articolo in questione afferma che parlare male della programmazione Object Oriented e' come "swearing in church". Comunque non ritengo offensiva nessuna affermazione ho riportato a favore della mia tesi.
Inoltre, come la maggior parte di voi, per portare il pane a casa PROGRAMMO, e lo faccio usando linguaggi orientati agli oggetti...

Mi sembra (opinione personale) che il numero di articoli contro l'OOP sia cresciuto parecchio in quest'ultimo anno. E' ora di preparare la "revolucion"

D'altronde non siete stanchi di usare ancora le stesse cose e riparare sempre gli stessi errori? Se qualcuno comincia a criticare lo stato delle cose, e' il benvenuto! E' il primo passo per tirar fuori qualcosa di nuovo...

cdimauro · 12-03-2009, 08:43

1) result = a.sin() * b + c # Questo è object oriented.

2) Non ho trovato finora un testo introduttivo alla programmazione che parta dalla programmazione a oggetti. Purtroppo la tendenza di chi fa informazione a livello divulgativo/scolastico è a introdurla dopo quella strutturata. Il che non significa che non sia adatta per partire con la programmazione. Forse qualche tutorial su SmallTalk affronta il problema da questo punto di vista.

3) "si tende", non significa che bisogna strafare.

4) la classe Object mette a disposizione diversi metodi di carattere generale che sono mediamente utili. Poi è ovvio che puoi scrivere applicazioni che non li usano.
Il discorso è esattamente lo stesso delle funzioni built-in disponibili nei linguaggi funzionali: perché metterle nel namespace condviso, anche se non servono? Dovrebbero essere importate soltanto all'occorrenza. Lo si fa proprio perché si tratta di funzioni mediamente utili.

5) Se la OOP viene usata male non è "colpa sua".

6) Questo capita anche coi paradigmi strutturati e funzionali, dove andare a trovare una funziona "scognita" può essere un'impresa. Dipende, al solito, da come si strutturano le cose.

7) Qui può aiutare l'approccio test driven, che tra l'altro "autodocumenta" il codice. Ma vale anche per gli altri paradigmi.

8) Le eccezioni non fanno parte del paradigma OOP: le si può introdurre anche negli altri.

9) Con Delphi non m'è mai capito di dover ricompilare un'applicazione soltanto perché ho cambiato l'implementazione di una classe. Inoltre è in grado di compilare sorgenti da un milione di righe di codice in pochi secondi (grazie alla struttura del linguaggio, che è modulare e richiede una sola passata).

10) Questo dipende dal tipo di linguaggio. Con Python, dove qualunque cosa è un oggetto, posso crearmi una sottoclasse di Tuple o List e ridefinire qualunque loro metodo, se è utile.

P.S. Anche le mie sono opinioni personali.

javaboy · 12-03-2009, 08:53

Quote:

Originariamente inviato da sottovento

Ne penso bene, mi trovo fondamentalmente d'accordo. E' forse un po' tiepido.

Penso che attualmente la programmazione ad oggetti sia ultra utilizzata (spesso a sproposito) e che sia ritenuta il non-plus-ultra. Non sono cosi' intelligente per poter fornire un'alternativa, ma sono sicuro che un'alternativa migliore esista. E se non esiste, i tempi sono maturi per trovarla.

D'altronde, la scienza (anche l'informatica) e' sempre progredita mettendo in discussione (spesso asserendo addirittura il contrario) i principi che venivano ritenuti assodati, no?

Forse l'articolo riporta troppo poche motivazioni. E' facile trovare altre motivazioni sul fatto che la programmazione ad oggetti abbia dei limiti e che sia ora di trovare qualcosa di meglio:

1 - result = sin(a) * b + c;
result = Math.Add (Math.Times (Math.Trig.sin(a), b), c);
Quale dei due e' piu' semplice? (NOTA - So benissimo che in C++/Java/... posso scrivere entrambe, e' un esempio per rendere l'idea). Quale delle due e' da considerarsi object-oriented?

2 - In questo forum vengono molto frequentemente postati dei messaggi di persone che vogliono imparare a programmare.
Sintetizzando, le risposte sono del tipo: "Impara a programmare con le procedure e poi passa alle classi".
Perche'? Sempre nelle stesse risposte si dice che la programmazione ad oggetti e' piu' naturale! Allora, perche' non si parte ad imparare le basi della programmazione ad oggetti, lasciando per ultima la programmazione piu' difficile?

3 - Quando si usano i linguaggi ad oggetti, si tende a modellare tutto con classi, cioe' "proprieta'" e "metodi" o "messaggi". Questo e' piu' naturale?
Per esempio:

Bicchiere bicchiere;
bicchiere.riempi (acqua);

Cosa c'e' di naturale di un bicchiere che si auto-riempie di acqua? NOTA - non e' un esempio forzato, succede tantissime volte in tutti i software che mi e' capitato di vedere in 20 anni di programmazione: gli oggetti che subiscono l'azione diventano gli attori della stessa.

Comunque, se si preferisce:
Bicchiere bicchiere;
Acqua acqua;
acqua.riempi (bicchiere);
Sembra piu' naturale? Meno male che l'acqua ha un metodo per riempire il bicchiere

4 - Perche' lo stesso bicchiere deve ereditare dalla classe Oggetti? E dalla classe Vetro? Cosa c'e' di naturale in questo? Perche' mi devo portare dietro dei "Metodi/Messaggi" che non mi serviranno a niente, visto che il mio programma usera' il bicchiere per bere l'acqua?

5 - La OOP funziona bene quando e' chiaro cosa deve FARE la classe. Assume che la classe sia un modello di qualcosa che l'utente della stessa conosce gia', nella realta'.
Per esempio, ho appena trovato una classe (in un software scritto da altri) di questo tipo:

class ModelizePlantWithEdgerWithoutL3System: public ModelizePlantWithEdgerOnDownstream
{
....
};

Ritengo di essere del settore (a cui questo software si riferisce), ma credetemi o meno non so come usare la classe!!
Riassumendo: se scrivi una classe che si chiama complex_number probabilmente tutti riescono ad usarla. Quando le cose diventano piu' complesse, siccome la classe si basa sulla conoscenza personale (del singolo programmatore) utilizzare la classe non e' piu' cosi' immediato.
Questo vale a maggior ragione quando la classe ha uno stato, e che obbliga lo sviluppatore a chiamare i metodi in sequenze ben determinate. Ma gli oggetti hanno per forza uno stato!
Nella azienda dove lavoro, si e' riscontrato che l'inserimento di nuovo personale nei progetti esistenti richiede un tempo di training maggiore di qualche anno fa. Domanda: non si dovevano ridurre, questi tempi?

6 - Sempre per il motivo 5, se non e' chiaro cosa deve fare le classe, l'ereditarieta' non fa altro che peggiorare le cose. E' come se il famoso INCAPSULAMENTO (inteso come dati e algoritmi nella stessa classe, i.e. nello stesso posto) venisse a mancare. In sostanza, non sai piu' dove andare a trovare le cose. Dov'e' il metodo che fa questo? Ed il metodo che fa quello? Apri la classe corrispondente all'oggetto con il metodo bacato, ma non lo trovi! Allora devi "risalire la china" delle ereditarieta', sperando di trovarlo.
Lasciamo ovviamente stare il costrutto friend, perche' ho voglia di piangere.

7 - Quando il software comincia a crescere, hai bisogno di un valido software per la documentazione automatica e la ricerca dei metodi. Purtroppo quando si comincia ad usare PESANTEMENTE il polimorfismo, potresti perdere giorni a cercare qual e' esattamente il metodo che viene eseguito ad una determinata condizione. Sto ovviamente parlando di software di milioni di righe, ma e' pur vero che in programmi con programmazione tradizionale NON perdevo quel tempo per cercare cosa succede, anche se il codice risultante era meno elegante (magari sequenze di switch()).
Con l'arrivo della programmazione ad oggetti, e' arrivata anche una serie di nuovi tool di cui prima non si sentiva l'esigenza. Ora sul muro del laboratorio c'e' un grande poster che descrive il diagramma delle classi, tanto per dare un'idea di cosa succede, ed abbiamo un software da 2000$ (per ogni PC) per tener aggiornato il progetto.
Intendiamoci: e' anche vero che il software e' cresciuto nelle dimensioni. Pero' e' anche vero che per poter avere un'idea di cosa sta succedendo si ha bisogno di altri tool, piu' potenti. Anche il semplice editor ti deve ora mostrare la lista dei metodi disponibili per oggetto, e spesso scrivere un programma significa scandire questa lista, alla ricerca del metodo "giusto" (cioe' che "suona" bene). Purtroppo di metodi che suonano "giusti" ce ne sono sempre 3 o 4...
Domanda: come sarebbe la produttivita' in generale senza questi tool? Per ogni metodo si dovrebbe andare a scorrere la documentazione?

8 - Le eccezioni!!! Basandosi su quanto viene affermato anche in comp.lang.c++.moderated (oppure basta leggere "Exceptional C++" del mitico Herb Sutter), ben pochi programmatori hanno capito fino in fondo cosa significa utilizzare le eccezioni (il sottoscritto si ritiene incluso nella lista degli ignoranti). Gli esempi che riporta sono a dir poco illuminanti.
Scrivere codice SICURO rispetto alle eccezioni e' un'impresa non da poco, nonostante tutti si dichiarino ben preparati nel loro uso.
Inoltre, se pensiamo che erano nate per evitare di mischiare il normale flusso di esecuzione dal flusso di esecuzione degli errori, mi viene quasi da piangere: nel codice che ho potuto vedere in questi anni, questo obiettivo non e' stato mai raggiunto. Altro che naturale!!!
In piu', con le eccezioni si doveva eliminare una volta per tutte il blind faith. Ho bisogno di aggiungere altro?
Forse si: qualcosa sulla propagazione delle eccezioni. Fino a quando deve essere propagata un'eccezione? Qual e' il giusto livello per catturarla in maniera efficiente?
In pratica, nella maggior parte del codice che ho visto:
- non si catturano eccezioni importanti ed il programma termina quando vengono sollevate;
- si catturano subito e si riporta un codice di errore (ORRORE! Non eravamo tutti orientati agli oggetti?)
- si catturano e si tappano con un orrendo catch (...).
E se l'eccezione e' riportata da una libreria che hai acquistato, e che magari e' carente nella documentazione? (quale documentazione riporta le eccezioni, e soprattutto, chi le legge?).
In piu', le eccezioni possono generare un sacco di problemi molto carini. Per esempio, sempre leggendo comp.lang.c++.moderated si puo' scoprire che il seguente codice:

MyObject *vect = new MyObject[100];
-- qui usiamo questo vettore, poi:
delete[] vect;

puo' generare dei memory leak ASSOLUTAMENTE NON ELIMINABILI. Quale istruzione genera il memory leak? Ovviamente delete[] vect!!!!

9 - Qualcuno vocifera che se la parte pubblica di una classe non cambia e si cambia solo la parte privata, basta ricompilare
il sorgente della classe e linkare al resto. BALLE. Non per nulla, si sono disegnate architetture (che, fra l'altro, trovo molto eleganti) come COM anche per ovviare a questo.
Esempio:
MyObject *pObject = new MyObject;
Prova a NON ricompilare questa istruzione nel tuo codice che usa l'oggetto MyObject.
In sostanza: cambi la parte privata? Prego, ricompila anche il tuo codice sorgente esattamente come facevi prima. Ci impieghi ore? Ce ne impiegavi anche prima, no?

10 - Ultima parola sul polimorfismo. Altra arma a doppio taglio, visto che non si puo' usare con i vettori! Chi sa cosa succede usando un vettore di oggetti polimorfici? Nessuno! Per fortuna non e' un errore molto comune nel software che mi e' capitato di vedere.

Disclaimer: ovviamente queste sono opinioni personali (piu' qualche *vera* dimostrazione). Anche l'autore dell'articolo in questione afferma che parlare male della programmazione Object Oriented e' come "swearing in church". Comunque non ritengo offensiva nessuna affermazione ho riportato a favore della mia tesi.
Inoltre, come la maggior parte di voi, per portare il pane a casa PROGRAMMO, e lo faccio usando linguaggi orientati agli oggetti...

Mi sembra (opinione personale) che il numero di articoli contro l'OOP sia cresciuto parecchio in quest'ultimo anno. E' ora di preparare la "revolucion"

D'altronde non siete stanchi di usare ancora le stesse cose e riparare sempre gli stessi errori? Se qualcuno comincia a criticare lo stato delle cose, e' il benvenuto! E' il primo passo per tirar fuori qualcosa di nuovo...

Molti di questi problemi però sono relativi al c++, non alla programmazione ad oggetti in generale.

sottovento · 12-03-2009, 09:39

Quote: