Newsgroup: it.comp.programmare
Titolo: Classi ed ereditarietà

Ciao,
vorrei sapere secondo voi quale stile di programmazione è migliore in
assoluto, o se, come spesso accade, "dipende".....
class pippo
{
    int a;
    int b;
    void stampa()
    { // implementazione}
}
class pluto:pippo
{
    int c;
    int d;
}
oppure
class pippo
{
    int a;
    int b;
    int c;
    int d;
     void stampa()
    { // implementazione}
}
class pluto:pippo
{
        // riempio solo alcuni campi.
}
Mi trovo a dire che per una questione di generalità assoluta è meglio la
seconda soluzione, per esempio sono un client e non conosco il particolare
pluto, per cui:
pippo MioPippo=RiceviUnaClassePippoDallaRete(); // quella che ricevo in
realtà è un pluto.
pippo.stampa();
e mi stampa solo i valori diversi da null.
Però c'è un difetto dovuto al fatto che un'altra classe mickey derivata da
pippo potrebbe contenere alcuni campi che non gli competono per niente e per
sbaglio potrei andarli a settare combinando un macellino.
Che ne dite?
Lu

 Che ne dite?
Una classe base dovrebbe essere indipendente dalle possibili sottoclassi,
quindi l'idea di aggiungere campi c e d a pippo (che tra l'altro NON
possono "essere null", ne` in C++, ne` in Java: un int in entrambi i
linguaggi HA sempre un preciso valore...!!!) e` pessima.  Dovrebbe invece
essere virtuale il metodo 'stampa', cosi` da SAPERE esattamente di che
classe si sta occupando e quindi cosa debba stampare.  (Naturalmente
bisogna che la "spedizione in rete" degli oggetti conservi in modo
corretto la virtualita` ecc ecc, ma mi pare che Java garantisca tutto
questo -- naturalmente in Java per "virtuale" leggi "non final").
Alex

 questo -- naturalmente in Java per "virtuale" leggi "non final").
Fin qui tutto chiaro, la virtualità è garantita dall'abstract. Però perchè è
necessaria l'indipendenza? Non trovo che la seconda soluzione sia così
pessima....
Lu

 pessima....
Forse il modo + semplice di spiegare perche` una classe dovrebbe essere
indipendente dalle sue sottoclassi e` l'open-closed principle, che trovi
a 
http://www.brent.worden.org/articles/2000/openClosedPrinciple.html
 e
in migliaia (letteralmente) di altri siti web.
Alternativamente, vedila cosi`: ovviamente una classe dipende dalla
sua superclasse (e` inevitabile).  Se inoltre la superclasse dipende
dalla sottoclasse hai appena creato (inutilmente, tra l'altro) un
circolo vizioso di mutua dipendenza.  Le mutue dipendenze sono un
disastro e vanno (spero che sia ovvio!) evitate quasi a tutti i costi:
le frecce di dipendenza fra componenti software devono definire un
grafo aciclico _E_ devono andare DA "componenti meno stabili" A
"componenti piu` stabili" (e` un nonsenso che un componente che, di
suo, sarebbe stabile, perda la stabilita` per l'uzzo di dipendere
da uno che stabile non e`!).  Robert Martin e` l'autore che ha meglio
trattato ed evidenziato questi temi, e non a caso infatti consiglio
sempre il suo testo (premio Jolt 2002) sulla "programmazione agile".
Ma li trovi trattati in profondita` anche in testi classici come il
Lakos "Large Scale C++ Programming".  Comunque, Martin ha in particolare
codificato il "Dependency Inversion Principle" che mostra come rendere
aciclico e correttamente orientato un grafo di dipendenze che, di suo,
non "vorrebbe" esserlo (si tratta in sostanza di evidenziare delle
interfacce, intrinsecamente stabili, che isolano ed estraggono le
dipendenze che vogliamo togliere di mezzo).  Sul sito di ObjectMentor
trovi molti degli scritti di Martin.
Di questi "grandi testi" non c'e` ancora molto imperniato sul C#, anche
solo perche` e` abbastanza nuovo.  Ma in sostanza tutto quello che
leggi sul Java (e molto di quello che leggi sul C++, esclusi concetti
non applicabili a C# / Java come la gestione necessariamente esplicita
della memoria, l'uso dei template, ecc) e` applicabile anche in C# (e
in molti casi in qualsiasi altro linguaggio, anche semanticamente molto
diverso).
Alex

 ha scritto nel messaggio
news:_Myeb.203006$R32.6...@news2.tin.it...


 Ti ringrazio,
Prego!  Hai pienamente ragione sullo "sbandare un po' all'inizio",
tra l'altro.  "Object-Oriented Software Construction" di Meyer e`
un grande libro come guida al tema, purtroppo imperniato solo su
Eiffel, non un linguaggio molto diffuso ne` "comodo", ahime`.
Alex