OOP: mostratemi la luce

[Kemper Boyd]

Ci sono cose che studi, leggi, ristudi e rileggi ma non le capisci davvero finche' non ti fanno "click". Io sono passato attraverso diversi linguaggi di programmazione, ma ho sempre seguito la filosofia "classica" procedurale, e gli oggetti - benche' abbia chiare le nozioni di base - non mi hanno mai "fatto click".

Qualcuno puo' spiegarmi in cosa *veramente* la OOP e' diversa? Cosa cambia sostanzialmente? Cosa si puo' fare solo in OOP? Spero che stavolta mi facciano click

[Firestorm]

Dipende tanto io programmo poco ad oggetti, lo faccio solo quando ne sento la necessità perchè il problema si presta molto bene se no rimango al classico.

[Xan]

In oop modelli il comportamento dell'applicazione come oggetti dinamici interagenti fra loro. questi oggetti sono ciascuno dotati di un proprio stato interno e di proprie funzioni. hai presente il c? hai presente (moooolto vagamente eh) le struct? ecco, l'oop usa strutture dati che modellano contemporaneamente stato e comportamento. così ad esempio puoi far accedere le variabili di un oggetto solo attraverso certe funzioni definite per quell'oggetto (e così evitare che qualcuno si registri ad un servizio online con data di nascita 1345 ad esempio ). l'informazione cioè puoi gestirla in maniera più "sicura" (incapsulamento), regolandone l'accesso solo agli autorizzati, usando anche un meccanismo di namespace / packages (così avrai certe "proprietà" visibili solo in certi ambiti e non tutto ovunque come in c). Nel'oop c'e il concetto di classe (fabbrica di oggetti molto rozzamente ma non solo) e di oggetto (dinamico, creato da una classe). puoi creare vere e proprie gerarchie di classe in cui una è una generalizzazione dell'altra, mantenendo per quella più specifica le proprietà della più generale senza dover riscrivere il relativo codice.
diciamo che più un sistema è complesso da modellare, più si va incontro i limiti della programmazione strutturata, e l'oop è più indicata come scelta.
PS: in realtà ciò che ho detto si riferisce di più all'ood (object oriented design)

[Kemper Boyd]

così ad esempio puoi far accedere le variabili di un oggetto solo attraverso certe funzioni definite per quell'oggetto (e così evitare che qualcuno si registri ad un servizio online con data di nascita 1345 ad esempio )

Non ho capito molto bene questo esempio, un controllo di validita' dei dati inseriti non mi sembra esclusivo degli oggetti, no?

[Xan]

Non ho capito molto bene questo esempio, un controllo di validita' dei dati inseriti non mi sembra esclusivo degli oggetti, no?

non è esclusivo, ma con gli oggetti puoi gestire ogni singola interazione esterna con le varabili stesse degi oggetti in molti modi
nella poo esistono metodi chiamati "accessori" che essenzialmente stabiliscono le modalità secondo cui le variabili possono essere modificate/accedute.
in generale, con oggetti e programmazione procedurale puoi fare più o meno le stesse cose (puoi programmare ad oggetti in assembly!), ma alcune cose sono più naturali/eleganti/manutenibili nella controparte ad oggetti.

[Haruki]

Dipende tanto io programmo poco ad oggetti, lo faccio solo quando ne sento la necessità perchè il problema si presta molto bene se no rimango al classico.

Nel mercato del lavoro, ad oggi, la procedurale non la si usa quasi per niente.

[Kemper Boyd]

non è esclusivo, ma con gli oggetti puoi gestire ogni singola interazione esterna con le varabili stesse degi oggetti in molti modi
nella poo esistono metodi chiamati "accessori" che essenzialmente stabiliscono le modalità secondo cui le variabili possono essere modificate/accedute.
in generale, con oggetti e programmazione procedurale puoi fare più o meno le stesse cose (puoi programmare ad oggetti in assembly!), ma alcune cose sono più naturali/eleganti/manutenibili nella controparte ad oggetti.

Si ma parli come la tipica introduzione ad articoli che parlano di OOP: troppo generico e fumoso

Fai esempi concreti

[Firestorm]

Nel mercato del lavoro, ad oggi, la procedurale non la si usa quasi per niente.

Nelle società di sviluppo più che probabile altrove se fai l'informatico non ti danno il tempo di sviluppare classi e funzioni devi fare le cose bene e in fretta con gli strumenti peggiori (VBA for Excel o porcherie simili) e la programmazione ad oggetti per quanto più efficiente e migliore dalal punto di vista della progettazione ha bisogno di tempi superiori se devi progettare tutto da zero e non usare classi già formate...
Tendezialmente per mia esperienza per programamre ad oggetti hai bisogno di tempi iniziali più lunghi in cui non riesci a dare alcun risultato e se non lavori come sviluppatore non tel i puoi permettere...poi SICURAMENTE se bene progettato un programam ad oggetti è nell'ordine
1) mediamente più semplice da scrivere,
2) più facile da mantenere,
3) probabilmente con molto più codice riutilizzabile.

Purtroppo almeno a mio parere ci sono 2 tipi di svilupaptori quelli "fortunati" (dico fortunati in maniera non corretta perchè molte volte lavorano in condizioni pessime in società che li sfruttano) che grazie ad una decente pianificazione del alvoro hanno la possibilità di progettare un lavoro e lavorare in maniera organica su un progetto, e tanti altri che teoricamente fanno altro ma che svilupapno piccoli progetti specifici per l'azienda in cui lavorano ma che hanno tempi molto stretti in cui dare risutlati senza la possiiblità di fare un buon progetto a causa dell'ottusità di alcuni...
Poi c'è tutta la programmazione di dispositivi elettronici e li gli oggetti non esistono...

[Xan]

@Firestorm: in realtà, progettando ad oggetti non hai grossi risultati nella primissima fase del progetto, ma più vai avanti più la rapidità nello sviluppo si sente, a meno che l'ood non sia considerato solo per manierismo, nel qual caso non se ne afferra lo spirito e si fanno sforzi inutili...
certo, se il tuo capo pretende che tu stia a pigiare la tastiera a partire dall'istante immediatamente successivo a quello in cui ha finito di darti le direttive è tutt'altro discorso...ma il mio giudizio su un capo del genere sarebbe prettamente negativo

[Haruki]

Nelle società di sviluppo più che probabile altrove se fai l'informatico non ti danno il tempo di sviluppare classi e funzioni devi fare le cose bene e in fretta con gli strumenti peggiori (VBA for Excel o porcherie simili) e la programmazione ad oggetti per quanto più efficiente e migliore dalal punto di vista della progettazione ha bisogno di tempi superiori se devi progettare tutto da zero e non usare classi già formate...
Tendezialmente per mia esperienza per programamre ad oggetti hai bisogno di tempi iniziali più lunghi in cui non riesci a dare alcun risultato e se non lavori come sviluppatore non tel i puoi permettere...poi SICURAMENTE se bene progettato un programam ad oggetti è nell'ordine
1) mediamente più semplice da scrivere,
2) più facile da mantenere,
3) probabilmente con molto più codice riutilizzabile.

Purtroppo almeno a mio parere ci sono 2 tipi di svilupaptori quelli "fortunati" (dico fortunati in maniera non corretta perchè molte volte lavorano in condizioni pessime in società che li sfruttano) che grazie ad una decente pianificazione del alvoro hanno la possibilità di progettare un lavoro e lavorare in maniera organica su un progetto, e tanti altri che teoricamente fanno altro ma che svilupapno piccoli progetti specifici per l'azienda in cui lavorano ma che hanno tempi molto stretti in cui dare risutlati senza la possiiblità di fare un buon progetto a causa dell'ottusità di alcuni...
Poi c'è tutta la programmazione di dispositivi elettronici e li gli oggetti non esistono...

Volendo puoi usare oggetti anche nella programmazione di lavatrici e microonde eh. La cosa più evidente che ti da l'OOP in più rispetto alla procedurale è l'ordine, che ti semplifica un casino il lavoro.

Poi è ovvio che ci siano parti che devi fare proceduralmente.

[Mithrandir]

Sfatiamo un po' di miti:
- non è vero che con l'OOP non si fan le cose rapidamente, è solo questione di abitudine e forma mentale nel pensare le soluzioni
- bene e in fretta sono impossibili a sostenersi nello stesso contesto se non accompagnati da "costoso", infatti nelle società non di sviluppo in genere il risultato è male e in fretta, ma che fa quel tanto che può bastare alla necessità contingente.
Che è anche giusto fino ad un certo punto, non lo è più nel momento in cui si manca di aver un attimo di lungimiranza per spendere un po' di tempo e denaro in più al tempo zero per risparmiarne un sacco dopo.
Ma questo spesso purtroppo non è nelle mani di chi sviluppa.
- In genere a chi sta su però, frega na mazza se si sviluppa ad oggetti, o a topi morti, frega il risultato, a meno che un certo tipo di tecnologia / tecnica non rientri vagamente nell'interfaccia commerciale o desiderata del cliente. Quindi basta sviluppare ad oggetti ogni volta che ti pare sia utile e bon. La lentezza deriva solo da mancanza di dimistichezza con quel tipo di design. E oramai qualsiasi IDE integrata è un aiuto alla generazione di codice che accelera ancora di più la produttività.

Il vantaggio principale dell'OOP è quello che veniva sbandierato quando l'OOP lanciava i suoi primi vagiti, ma oggi si tende a dimenticarsene: incapsulamento, struttura ordinata, blah blah, tutto vero...ma il fondamentale si riassume in una sola affermazione:
"Pensa ad oggetti per il semplice motivo che vivi in un mondo di oggetti"
Oggetti con proprietà e che compiono operazioni.
Quando ci si rende conto che l'OOP non è altro che un modo di accelererare ( incredibile eh? ) il design fornendo uno strumento che ti permette di pensare allo stesso modo in cui pensi quando fai una frittata o guidi l'auto ... l'OOP oltre che dare tutti i vantaggi a corollario, diventa anche rapido e naturale.

Se devo sviluppare un simulatore automobilistico, mi servono un auto. un auto ha quattro ruote, 2 sportelli, un motore, colorata, una chiave, i finestrini ... stop. Mi serve tutto questo?
No, io voglio qualcosa di più semplice, quindi ho bisogno di un'auto, che si può accendere, spegnere, posso accelerare e frenare e guardarne il colore.
Non c'è una riga di codice, ma praticamente l'oggetto è già definito.

Da qui a far questo:

public interface Auto {

    public void accelera(int forza) throws SpentaException;
    public void frena(int forza) throws SpentaException;
    public void accendi();
    public void spegni();
    public int getVelocita();

}

son trenta secondi netti

e da qui a far questo:

public class SempliceAutoRossa implements Auto {

    public static int DEFAULT_SPEED_STEP =   5;

    private int velocita    =   0;
    private final String color    =   "Rosso";
    private boolean accesa  =   false;

    public void accelera(int forza) throws SpentaException {
        if (!accesa)
            throw new SpentaException();
        velocita += forza * DEFAULT_SPEED_STEP;
    }

    public void frena(int forza) throws SpentaException {
        if (!accesa)
            throw new SpentaException();
        velocita -= forza * DEFAULT_SPEED_STEP;
    }

    public void accendi() {
        this.accesa =   true;
    }

    public void spegni() {
        accesa = false;
    }

    public int getVelocita() {
        return velocita;
    }

    public boolean isAccesa() {
        return accesa;
    }

    public void setAccesa(boolean accesa) {
        this.accesa = accesa;
    }
}

Cosa hai fatto?
Hai definito un interfaccia, qual è il vantaggio? Che chiunque nel codice usi le tue auto, se ne frega di come "dentro" le auto funzionino ( esattamente come tu te ne freghi di sapere esattamente quanto carburante viene combusto ad ogni ciclo del motore ), usa l'interfaccia.
Cosa ti permette di fare?

Quel che qualcuno ti diceva poco sopra, di scrivere la tua prima implementazione ( il secondo codice ) di una semplice auto rossa, che è quell'implementazione fatta in fretta e bene ( questa volta sul serio ) che il tuo capo ti chiede.

Però ... se un domani il tuo capo ti dice, voglio una Jaguar nera con un'accelearazione pazzesca appena sfioro il pedale ( chiamo accelera() ), tu non sei costretto a rispondere: eh, che casino, devo rifare l'implementazione delle funzioni di accelerazione dell'auto, ma allora devo cambiare alcune cose che ci stanno attorno, eh allora ... no, puoi guardarlo serenamente in faccia e dire: e che ci vuole. Cambio solo l'oggettino che dice COME l'auto accelera, e forse neanche ( ma questo è troppo tecnico, tienlo per te ), mi basta estendere la mia SempliceAutoRossa così:

public class JaguarNera extends SempliceAutoRossa implements Auto {
    JaguarNera() {
        DEFAULT_SPEED_STEP = 20;
        color = "Nera";
    }
}

Quanto ci hai messo? 10 secondi a dir tanto, e hai la tua bella jaguarnera che accelera ( e frena ... visto le velocità, meglio ) di brutto.

Ovviamente in questo esempio ci son tante cose che sarebbero da raffinare, correggere, rivedere... per fare l'interfaccia magari ci si ferma 2 minuti invece di 30 secondi...e si specificano bene le esigenze che si hanno. ( ad esempio ho dimenticato nell'interfaccia un modo per sapere il colore )

Però dovrebbe darti un'idea di cosa voglia dire pensare ad oggetti, che è diverso da scrivere codice ad oggetti.

Se questo esempio ti è utile dammi un feedback, che io poi li riuso a volte, quando devo far un po' di formazione rapida

[Kemper Boyd]

Mithrandir, ti ringrazio per la risposta molto dettagliata, quello che dici e' chiaro ma a me rimane il dubbio fondamentale per cui - per come la vedo io - la OOP e' solo un modo di scrivere le cose "al contrario".

Faccio un esempio, consideriamo un accesso a database (sintassi buttata li'):

// versione OO
$dbobj = new Db("host", "user", "pass");
$dbobj->select_db("test");
$dbobj->query("SELECT * FROM clienti");
$dbobj->get_result_set();
// eccetera

// versione standard di librerie di funzioni
$link = db_connect("host", "user", "pass");
select_db("test", $link);
$query = db_query("SELECT * FROM clienti");
get_result_set($query);
// eccetera

Alla fine e' questo che non mi entra in testa, mi sembra solo che la differenza sia nello scrivere una variabile prima della freccia del metodo anziche' nella parentesi come argomento

[Mithrandir]

Vista così sembrerebbe...ma esempi così banali è ovvio che ti eliminano la visibilità dei vantaggi che ne avresti.

Intendiamoci, no morte alla programmazione procedurale: consapevolezza però dei limite oltre un certo livello di complessità.

Pensa però che quei metodi "dopo la freccia" siano le chiamate che tu fai ad esempio su un'interfaccia.
Significa che tu non hai assolutamente idea della reale implementazione,e chi sviluppa può cambiartela sotto il sedere senza che tu te ne accorga continuando a far funzionare ( in a bugless life ) la tua applicazione.

Immagina che la funzione per selezionare il db, però un giorno cambi, e non vuole più come parametro il tipo ritornato da db_connect ( $link ), rimaniamo nell'ambito di linguaggi tipizzati eh.
Cosa dovresti fare?
Dovresti riscrivere la db_connect, perchè ritorni un altro tipo,oltre che aver riscritto la select_db.

Nel primo caso però, tu hai un dbobj ... che presumibilmente ( anche il buon design oop ha dei limiti ) sarà sempre un oggetto che vuol sapere host, user,pwd e un nome di db per farti avere accesso ai dati.
Del resto non ti frega, crei l'oggetto, qualcuno ha scritto la sua implementazione e un giorno o l'altro te la può cambiare perchè cambia il modo di fare la connect e i tipi che ritorna, ma a te frega solo che si attacchi ad un db e ti ritorni un risultato a delle query.

E' un po' dura vederlo in esempi così piccoli, però all'aumentare della complessità, ne vedi i vantaggi.

E' naturale che se devi fare un aggeggino quick&dirty la programmazione procedurale ( o anche l'approccio: accrocchio un po' di pezzi assieme ), va più che bene, s'è usata per anni e si son fatte fior di cose...alla fin fine.

Prova poi a pensare ad esempio ad un progetto con un plan di sviluppo con diversi moduli in parallelo, e alcuni di loro sono dipendenti, ma devono esser sviluppati assieme.
Come dire, il modulo A usa il modulo B, ma A e B li sviluppo assieme. A come fa ad usare qualcosa che non esiste?
Semplice, si fa il design del bocchettone di attacco, si definiscono interfacce, che non fan nulla, son stupide... ma si sa cosa dovrebbero fare e cosa dovrebbero restituire e ognuno può andar per la sua strada.

Una volta il sw si sviluppava in seriale, praticamente ... ora, sopratutto con il tambur battente del mercato e della concorrenza, non te lo puoi permettere.

[Kemper Boyd]

Immagina che la funzione per selezionare il db, però un giorno cambi, e non vuole più come parametro il tipo ritornato da db_connect ( $link ), rimaniamo nell'ambito di linguaggi tipizzati eh.
Cosa dovresti fare?
Dovresti riscrivere la db_connect, perchè ritorni un altro tipo,oltre che aver riscritto la select_db.

Nel primo caso però, tu hai un dbobj ... che presumibilmente ( anche il buon design oop ha dei limiti ) sarà sempre un oggetto che vuol sapere host, user,pwd e un nome di db per farti avere accesso ai dati.
Del resto non ti frega, crei l'oggetto, qualcuno ha scritto la sua implementazione e un giorno o l'altro te la può cambiare perchè cambia il modo di fare la connect e i tipi che ritorna, ma a te frega solo che si attacchi ad un db e ti ritorni un risultato a delle query.

Ok pero' anche i metodi sono funzioni, no? Come puo' cambiare la chiamata di una funzione puo' cambiare anche quella del metodo. Mi sembra che spesso si paragonino cattiva programmazione procedurale con buona programmazione OO
A me non interessa l'implementazione di dbobj cosi' come non mi interessa l'implementazione di db_connect(); le funzioni non sono racchiuse in un'entita' come i metodi, ma comunque il loro utilizzo prescinde dalla conoscenza dell'implementazione.

Prova poi a pensare ad esempio ad un progetto con un plan di sviluppo con diversi moduli in parallelo, e alcuni di loro sono dipendenti, ma devono esser sviluppati assieme.
Come dire, il modulo A usa il modulo B, ma A e B li sviluppo assieme. A come fa ad usare qualcosa che non esiste?
Semplice, si fa il design del bocchettone di attacco, si definiscono interfacce, che non fan nulla, son stupide... ma si sa cosa dovrebbero fare e cosa dovrebbero restituire e ognuno può andar per la sua strada.

Non ho esperienza di lavoro in team, quindi non so commentare bene su questo, pero' - per fare un esempio - gli header file del C non possono essere considerati "bocchettoni"? Tu definisci i prototipi delle funzioni indipendentemente dalla loro implementazione che puoi fare in seguito.

Sia chiaro che non voglio assolutamente fare polemica, il mio intento e' davvero quello di capire la rivoluzione che il modello OO porta alla programmazione, le obiezioni che faccio sono proprio le cose che mi impediscono di fare quel "salto di comprensione"

[Mithrandir]

Per questo dico che anche con la programmazione procedurale si può fare del buon design.
Però con la programmazione ad oggetti sei portato a pensare facendo del buon design.
La procedura ha un input, un'esecuzione e un output, e ci si ferma lì.

Nell'OOP quel che produci è più potente, non puoi spiegarlo in termini Input -> esecuzione -> output -> fine.

L'oggetto ha uno stato, ha delle proprietà, ha una vita propria e ANCHE delle operazioni ( le procedure di una volta che ora si chiaman metodi ) con cui può agire e interagire con altri oggetti.

E ha una potenza descrittiva del tuo dominio applicativo che non puoi avere con semplici procedure.

Potrai dire, ma le proprietà son le variabili, eh si ... ma una volta si avevano i sw con carrettate di variabili globali ( e lo so perchè li facevo anche io ) che non si capiva che cacchio servissero.

Immagina di avere tanti oggetti, ma le loro proprietà non sono descritte dagli oggetti stessi, ma buttate alla rinfusa in uno scatolone.
La volta che trovi due proprietà di larghezza vai a capire se è la larghezza del mio portatile o della scrivania ... ( si, ok, chiami le variabili diversamente, ma astrai dal codice, pensa al sw come oggetto che risolve un problema al suo meglio ).

Se invece hai degli oggetti, ognuno è autocontenuto con le sue proprietà, così come il mio portatile "possiede" la sua larghezza, altezza, e l'uscita video, oltre alle operazioni ( sempre le procedure che adesso si chiaman metodi ) che puoi fare.

Un applicativo è un mondo di cose che fanno qualcosa ... o non fanno, quale modo migliore di descriverlo così come descriviamo quel che ci sta attorno tutti i giorni?
O ancora: il tuo portatile non è solo la procedura di accensione, è anche un monitor con tot.pollici, 105 tasti e un ingresso usb...che nella procedura di accensione possono o non possono concorrere.

Il fatto è che rimandendo su "esempietti" semplici, non si può coglierne le potenzialità, proprio perchè non è in quei casi che si rende utile, seppur anche in quei casi è utilizzabile senza ( avendo una certa maneggevolezza col metodo ) perdere in tempo e semplicità.

E' un po' come chiedersi quale sia il vantaggio di usare una turboelica rispetto ad un'elica, e poi usare come esempio un biplano. ( nessun vantaggio, manco la regge, o no? )

Mamma che logorroico che sono.
Però è dura ( puff, pant ) trasmettere anni di esperienza sul campo con uno schiocco di dita, e anche trovare il modo migliore per esprimere una cosa che non sta tanto nella sintassi del codice che scrivi, quanto nell'approccio di descrizione di un sw.
Il consiglio è ... sperimenta, procedurale, oggetti, dal semplice al complesso, sarai tu a capire quando e come usare una o l'altra soluzione, che non si sopprimono a vicenda.

[Kemper Boyd]

Beh immagino che meglio di cosi' non si possa spiegare, credo che dovro' provare per capire davvero. Ti ringrazio

[Firestorm]

Io sono assolutamente pro oggetti la mia tesi la ho fatta in python tutta ad oggetti ma adesso gli oggetti me li sogno perchè non lavorando in una azienda di informatica chi mi chiede qualcosa si aspetta che tempo 13 secondi dopo avermi dato la specifica io sono li a scrivere codice...E' UNA BESTEMMIA perchè poi si lamentano che la roba non funziona o peggio funziona male ma purtroppo al gente pensa che scrivere codice sia l'unico modo di programmare...mi sono dovuto convertire al VBa for Excel (che è veramente osceno) per fare in fretta e non generare file exe che sono puntualmente bloccati dalle policy di sistema di ogni pc dell'azienda...adesso sto facendo un corso ABAP interno all'azienda voglio vedere ora cosa mi chiederanno...rido per non piangere...

Piccolo appunto la vedo grigia scrivere codice assembler per schede elettroniche ad oggetti...comunque se dici che si fa mi fido...

[Kralizek]

Io sono assolutamente pro oggetti la mia tesi la ho fatta in python tutta ad oggetti ma adesso gli oggetti me li sogno perchè non lavorando in una azienda di informatica chi mi chiede qualcosa si aspetta che tempo 13 secondi dopo avermi dato la specifica io sono li a scrivere codice...E' UNA BESTEMMIA perchè poi si lamentano che la roba non funziona o peggio funziona male ma purtroppo al gente pensa che scrivere codice sia l'unico modo di programmare...mi sono dovuto convertire al VBa for Excel (che è veramente osceno) per fare in fretta e non generare file exe che sono puntualmente bloccati dalle policy di sistema di ogni pc dell'azienda...adesso sto facendo un corso ABAP interno all'azienda voglio vedere ora cosa mi chiederanno...rido per non piangere...

Piccolo appunto la vedo grigia scrivere codice assembler per schede elettroniche ad oggetti...comunque se dici che si fa mi fido...

ABAP vuol dire che vai a finire che programmare su SAP, che ****!

[fedyx]

Io sono assolutamente pro oggetti la mia tesi la ho fatta in python tutta ad oggetti ma adesso gli oggetti me li sogno perchè non lavorando in una azienda di informatica chi mi chiede qualcosa si aspetta che tempo 13 secondi dopo avermi dato la specifica io sono li a scrivere codice...E' UNA BESTEMMIA perchè poi si lamentano che la roba non funziona o peggio funziona male ma purtroppo al gente pensa che scrivere codice sia l'unico modo di programmare...mi sono dovuto convertire al VBa for Excel (che è veramente osceno) per fare in fretta e non generare file exe che sono puntualmente bloccati dalle policy di sistema di ogni pc dell'azienda...adesso sto facendo un corso ABAP interno all'azienda voglio vedere ora cosa mi chiederanno...rido per non piangere...

Piccolo appunto la vedo grigia scrivere codice assembler per schede elettroniche ad oggetti...comunque se dici che si fa mi fido...

scrivere firmware richiede una certa vicinanza del codice con l'hw, non dico che non si possa usare linguaggi OO ma da che so io il massimo che ti puoi permettere è il C.

[zago]

Tra procedurale e OOP, oltre il modus operandi ovviamente diverso, gli aspetti che sento molto sono sicuramente la riusabilità, l'organizzazione del codice e l'efficienza nel seguire i design pattern più famosi.
Insomma, traduce in codice senza troppa fatica quanto si è progettato in fase di analisi.

Anche nel bug fixing è parecchio comodo: Se si struttura il codice in una serie di piccoli oggetti che fanno poche cose, trovare e correggere l'errore è sicuramente più facile, rispetto ad un procedurale hardcodato.

Forse nell'ottimizzazione può essere un po macchinoso:
Magari l'analisi che ha prodotto il codice era fatta benissimo, in modo elegante e lungimirante.. ma se poi si scopre che il risultato è fisiologicamente lento e computazionalmente costoso, c'è il rischio che si debba
riscrivere una buona parte delle classi, o peggio, delle Interfacce, per far posto magari a un codice più hardcodato, meno 'bello' ma più veloce :(

[Firestorm]

ABAP vuol dire che vai a finire che programmare su SAP, che ****!

Lo so però è carino ma poco versatile e molto tosto...


@fedyx:
Lo so ho programmato sia in x86 che sui Texas Instruments 21xx...
però ho visto programamre i turbocodici di cifratura (solo visti per una testi) per i satelliti e per le FPGA usavano un linguaggio molto simile al C ma object oriented e legato al tipo di HW in questo caso le FPGA delle texas instrument quindi pensavo che si fosse mosso qualcosa in quell'ambito visto che sono almeno 6 anni che non tocco assembler...