[Generico/OOP]Ereditarietà

[RaouL_BennetH]

Ciao a tutti

Ho molti dubbi sulla comprensione dell'ereditarietà nella programmazione ad oggetti.

Leggendo vari documenti, trovo ovunque scritto che l'ereditarietà si applica solo ed esclusivamente nel caso in cui ci sia una relazione del tipo "is-a".

Facendo un esempio molto banale, ecco i miei dubbi:

Classe "Azienda"
Classe "Cliente"

un cliente _è_ un'azienda ? mi rispondo di si

Mi fermo un attimo su questo primo punto:

Con la classe base Azienda, è corretto pensare che NON è la mia azienda ma un'astrazione dell'entità azienda? Cioè, dovrò poi utilizzare questa classe base per istanziare oggetti di tipo miaAzienda, aziendaCliente ?

Aiutatemi prima a fugare questi dubbi e poi, continuerò con gli altri

Grazie mille come sempre.

RaouL.

[^TiGeRShArK^]

Originariamente inviato da RaouL_BennetH

Ciao a tutti

Ho molti dubbi sulla comprensione dell'ereditarietà nella programmazione ad oggetti.

Leggendo vari documenti, trovo ovunque scritto che l'ereditarietà si applica solo ed esclusivamente nel caso in cui ci sia una relazione del tipo "is-a".

Facendo un esempio molto banale, ecco i miei dubbi:

Classe "Azienda"
Classe "Cliente"

un cliente _è_ un'azienda ? mi rispondo di si

Mi fermo un attimo su questo primo punto:

Con la classe base Azienda, è corretto pensare che NON è la mia azienda ma un'astrazione dell'entità azienda? Cioè, dovrò poi utilizzare questa classe base per istanziare oggetti di tipo miaAzienda, aziendaCliente ?

Aiutatemi prima a fugare questi dubbi e poi, continuerò con gli altri

Grazie mille come sempre.

RaouL.

Se i clienti per te possono essere solo aziende e non persone fisiche allora Cliente is a Azienda.
Anche la TuaAzienda is a Azienda.
Azienda praticamente deve contenere le caratterisitche comuni a tutte le aziende e TuaAzienda e Cliente quelle specifiche.

[mindwings]

In fase di Design cerca di assegnare ad ogni classe una responsabilita' ed un comportamento preciso(Carte CRC ) premesso questo ti consiglio di usare l'ereditarieta' solo quando tutte le sottoclassi usano lo stesso codice della classe padre ovvero non fanno overriding non ridefiniscono localmente il comportamento di un metodo...

[faccio riferimento a java]
Nei linguaggi ad oggetti hai 2 tipi di ereditarieta' quella di implementazione
implementation inheritance (quella che usa la parola chiave extends) e quella di interfaccia interface inheritance (quella che usa la parola chiave implements) di questi 2 tipi di ereditarieta' quella che ti garantisce maggior flessibilita' e' l'interface inheritance.

Uno dei principi dell' OOP dice, "Program to interface, not an implementation" - Considera che quando usi extends leghi le classi figlie ad una implementazione precisa quella della classe padre, mentre usando implements puoi in qualsiasi momento sostituire l'implementazione che usi con un'altra che rispetta lo stesso contratto (definito nell'interfaccia).

Cerca di andare in profondita' e non soffermarti sull'aspetto linguistico - bisogna capire le implicazioni che una certa decisione comporta e valutarne gli aspetti positivi/negativi, altrimenti rischi di prendere qualche abbaglio.

[^TiGeRShArK^]

Originariamente inviato da mindwings

In fase di Design cerca di assegnare ad ogni classe una responsabilita' ed un comportamento preciso(Carte CRC ) premesso questo ti consiglio di usare l'ereditarieta' solo quando tutte le sottoclassi usano lo stesso codice della classe padre ovvero non fanno overriding non ridefiniscono localmente il comportamento di un metodo...

[faccio riferimento a java]
Nei linguaggi ad oggetti hai 2 tipi di ereditarieta' quella di implementazione
implementation inheritance (quella che usa la parola chiave extends) e quella di interfaccia interface inheritance (quella che usa la parola chiave implements) di questi 2 tipi di ereditarieta' quella che ti garantisce maggior flessibilita' e' l'interface inheritance.

Uno dei principi dell' OOP dice, "Program to interface, not an implementation" - Considera che quando usi extends leghi le
classi figlie ad una implementazione precisa quella della classe
padre, mentre usando implements puoi in qualsiasi momento
sostituire l'implementazione che usi con un'altra che rispetta
lo stesso contratto (definito nell'interfaccia).

Programmare ad oggetti significa attribuire responsabilita' e comportamenti
cio' porta ad una pluralita' di implementazioni, ogni implementazione soddisfa determinati requisiti(per questo non bisogna legarsi ad una in particolare). Bisogna fare data abstraction questa e' la chiave.

In diversi casi è anche preferibile utilizzare la composizione rispetto all'ereditarietà...
Ma dipende dai vari casi, quindi avevo risposto solo in maniera generica rispetto a quello che avevo capito del suo particolare problema.
cmq anch'io sono assolutamente a favore dell'uso delle interfacce.

[RaouL_BennetH]

Innanzitutto grazie per le risposte.

Ma quindi, se non ho capito male, la mia classe base dovrebbe essere un'interfaccia?

[mindwings]

Originariamente inviato da ^TiGeRShArK^

In diversi casi è anche preferibile utilizzare la composizione rispetto all'ereditarietà...
Ma dipende dai vari casi, quindi avevo risposto solo in maniera generica rispetto a quello che avevo capito del suo particolare problema.
cmq anch'io sono assolutamente a favore dell'uso delle interfacce.

E' un altro principio "prefer composition over inheritance".
@Raoul ti consiglio di acquistare qualche libro, io alcune cose le comprendo leggendo, per esempio trovo molto interessante http://www.holub.com/payment/holub.on.patterns.html nei primi capitoli bene l'oop e da un significato alla parola pattern.

Giusto per dirne una:

L'autore descrive un sistema OO come un insieme di animali intelligenti
che parlano l'un con l'altro scambiandosi messaggi (la metafora di Alan Kay)
ed aggiunge "The most important facet of OO design is data abstraction."...
"All information is hidden. A given object doesn't have any idea of what the innards of other objects look like"...

"You may have read in a book somewhere that an object is a data structure of some sort combined with a set of functions, called methods, that manipulate that data structure.Balderdash! Poppycock!"

Qui l'autore denigra la definizione di oggetto come struttura dati + metodi... Nel seguito spiega il perche` ovvero una definizione "procedurale" infatti segue una sezione dal titolo "Getters and Setters Are Evil"
Effettivamente anche a me e' capitato di usare gli oggetti poco piu' come dei contenitori e vai di get e set XD... Questo a causa di Cay Horstmann e uno dei suoi libri bacati usato al primo corso di programmazione...
Che senso ha definire una dato privato e rendere pubblici metodi come get e set ?! Serve solo a complicarne l'accesso...

[mindwings]

Originariamente inviato da RaouL_BennetH

Innanzitutto grazie per le risposte.

Ma quindi, se non ho capito male, la mia classe base dovrebbe essere un'interfaccia?

Dipende come ogni cosa dei farci delle considerazioni, ti aiuto io.
Allora definendo un'interfaccia delinei un comportamento ovvero l'insieme
dei messaggi a cui l'oggetto che implementa l'interfaccia e' in grado di rispondere. Definisci solo le segnature dei metodi! Non l'implementazione. Cio' ti da maggior flessibilita'/puoi avere piu' implementazioni per l'interfaccia ma per contro aggiungi un livello di astrazione.
Se invece usi una classe semplice e' perche' non hai bisogno di maggior flessibilita' e ti va bene usare direttamente l'implementazione.
Infine c'e' la mezza misura la classe astratta una classe astratta e' una classe che ha almeno un metodo astratto ovvero viene definita solo la segnatura e non l'implementazione, le classi che implementano la classe astratta devono definire l'implementazione del metodo astratto.

per esempio
Collection contenitore1 = new LinkedList();

LinkedList contenitore2 = new LinkedList();

Nel primo esempio sto usando la programmazione per interfacce ovvero quando uso contenitore
invio messaggi all'oggetto utilizzando solo quelli definiti nella sua interfaccia Collection mentre
nel secondo caso uso l'interfaccia specifica di LinkedList(definita nella sua classe) e quindi ho sia
i messaggi di "tipo" Collection perche' LinkedList implementa Collection e sia i messaggi propri
di LinkedList come per esempio addFirst che ha senso per una lista ma non per una collezione
che e' un concetto piu' generale(infatti collection non ha il messaggio addFirst).

se per esempio voglio cambiare l'implementazione di contenitore1 e' sufficente
sostituire new LinkedList() con per es new HashSet e sono in una botte di ferro
perche' anche la classe HashSet implementa lo stesso contratto/intefaccia Collection
e non avro' errori... Mentre nel secondo caso contenitore2 sono bloccato non posso
fare cambiamenti perche' uso un implementazione concreta

Spero di aver chiarito un po' i tuoi dubbi

[mindwings]

"We can write good or bad programs with any tool. Unless we teach people how to design, the languages matter very little."

-David Parnas

Questa e' da incorniciare

[PGI-Bis]

Originariamente inviato da RaouL_BennetH

Con la classe base Azienda, è corretto pensare che NON è la mia azienda ma un'astrazione dell'entità azienda? Cioè, dovrò poi utilizzare questa classe base per istanziare oggetti di tipo miaAzienda, aziendaCliente ?

E' corretto. Ogni volta in cui dichiari una classe dichiari implicitamente un insieme di valori. I valori appartenenti a quell'insieme sono tutti e soli quei valori a cui sono applicabili le operazioni dichiarate nella classe.

[banryu79]

Originariamente inviato da mindwings

In fase di Design cerca di assegnare ad ogni classe una responsabilita' ed un comportamento preciso...

Questo è un'aspetto critico se si vuole progettare la soluzione in una corretta prospettiva OO.
Troppe volte ho commesso l'errore di trascurare una definizione iniziale chiara delle responsabilità per delineare in modo pulito le classi e il modo in cui interagiscono.
All'inizio forse non puoi sapere tutta la soluzione, ma lavorando su quello che conosci eseguire questa prima analisi può aiutare a farti capire altri aspetti della soluzione che ancora non conoscevi, nonchè a far saltar fuori nuove classi che ad una prima osservazione erano rimaste misconosciute.

Magari è un discorso un po' OT rispetto al tuo problema contingente, però penso che una corretta identificazione delle responsabilità possa facilitarti nell'individuare anche la "gerarchia emergente" delle stesse.

[RaouL_BennetH]

mindwings ha scritto:
Qui l'autore denigra la definizione di oggetto come struttura dati + metodi... Nel seguito spiega il perche` ovvero una definizione "procedurale" infatti segue una sezione dal titolo "Getters and Setters Are Evil"
Effettivamente anche a me e' capitato di usare gli oggetti poco piu' come dei contenitori e vai di get e set XD... Questo a causa di Cay Horstmann e uno dei suoi libri bacati usato al primo corso di programmazione...
Che senso ha definire una dato privato e rendere pubblici metodi come get e set ?! Serve solo a complicarne l'accesso

:sonoArrossito:

Ecco, mi hai dato il colpo di grazia

Già stavo pensando all'incapsulamento della mia classe base ......

[WarDuck]

Originariamente inviato da mindwings

[...] "Getters and Setters Are Evil"
Effettivamente anche a me e' capitato di usare gli oggetti poco piu' come dei contenitori e vai di get e set XD... Questo a causa di Cay Horstmann e uno dei suoi libri bacati usato al primo corso di programmazione...
Che senso ha definire una dato privato e rendere pubblici metodi come get e set ?! Serve solo a complicarne l'accesso...

Non a caso C# ha i getters e i setters di default che vengono richiamati sia in lettura che in scrittura, basta definire un

get { ... codice ... } e un set { ... codice ... } et voilà, vengono richiamati quando occorrono, senza complicarsi la vita con i metodi .

[^TiGeRShArK^]

Originariamente inviato da WarDuck

Non a caso C# ha i getters e i setters di default che vengono richiamati sia in lettura che in scrittura, basta definire un

get { ... codice ... } e un set { ... codice ... } et voilà, vengono richiamati quando occorrono, senza complicarsi la vita con i metodi .

ehmmm...
così fungono in realtà quelli automatici...

public class Person
{
   public string Name { get; set; }
   public int Age { get; set; }
}

[RaouL_BennetH]

Visto che l'avete tirato in ballo (il C# intendo...)

non è quindi una buona pratica di programmazione utilizzare delle proprietà mediante get e set ??

[Tommo]

Io sono certo che lo sia.
cioè, è indispensabile nei casi che get e set oltre a restituire/settare la variabile facciano anche qualcosa altro... cosa piuttosto comune in classi sufficientemente complesse.

Nel caso del get/set puro io li preferirei lo stesso, perchè impediscono all'utente di "spararsi nei piedi"... per esempio se tu offri l'accesso pubblico ad una variabile di una classe, a qualche furbo potrebbe venire in mente di prenderne il puntatore.
Al che, appena per qualsiasi motivo la elimini la parte user dell'applicazione crasha miseramente.

Per cui vi ricordo che il mondo della programmazione va a mode, ed eviterei di decidere come programmare sulla base di slogan
Questa roba lasciatela allo stadio plz.

[mindwings]

Originariamente inviato da RaouL_BennetH

Visto che l'avete tirato in ballo (il C# intendo...)

non è quindi una buona pratica di programmazione utilizzare delle proprietà mediante get e set ??

Dipende dal tipo di oggetto in generale no! Se per esempio ho un oggetto Termometro ha senso un metodo getTemperatura, in altri casi un oggetto non deve mai esporre i dettagli del suo funzionamento(e quindi i campi privati o metodi privati), se io definisco un campo come private e poi definisco
dei metodi pubblici get e set a questo punto non c'e' alcun senso a definire il campo come private perche' sto soltanto complicando l'accesso al dato
ma la sostanza non cambia, modifico un dettaglio relativo al funzionamento dell'oggetto e quindi mando parnas a cagare con la sua information hiding.

[mindwings]

Originariamente inviato da Tommo

Io sono certo che lo sia.
cioè, è indispensabile nei casi che get e set oltre a restituire/settare la variabile facciano anche qualcosa altro... cosa piuttosto comune in classi sufficientemente complesse.

Nel caso del get/set puro io li preferirei lo stesso, perchè impediscono all'utente di "spararsi nei piedi"... per esempio se tu offri l'accesso pubblico ad una variabile di una classe, a qualche furbo potrebbe venire in mente di prenderne il puntatore.
Al che, appena per qualsiasi motivo la elimini la parte user dell'applicazione crasha miseramente.

Per cui vi ricordo che il mondo della programmazione va a mode, ed eviterei di decidere come programmare sulla base di slogan
Questa roba lasciatela allo stadio plz.

Sono principi, piuttosto che chiedere ad un oggetto un suo campo privato per fare delle azioni bisogna dire all'oggetto fai questa azione per me.

Esempio:

Oggetto Impiegato, anziche' avere una God Class che raccoglie i dati da impiegato per fornire una visualizzazione via gui...

impiegatoRaoul.getName
impiegatoRaoul.getCognome
impiegatoRaoul.getCodiceFiscale

faccio questo impiegatoRaoul.displayInformazioniPersonali, se seguo la strada del get and set avro' una bella God class che
sicuramente colleghera' i dati ad un unica modalita' di presentazione di dati... (E se cambiabutto via tutto?)...

[mindwings]

Originariamente inviato da WarDuck

Non a caso C# ha i getters e i setters di default che vengono richiamati sia in lettura che in scrittura, basta definire un

get { ... codice ... } e un set { ... codice ... } et voilà, vengono richiamati quando occorrono, senza complicarsi la vita con i metodi .

Zuccherino sintattico?!

[RaouL_BennetH]

Originariamente inviato da mindwings

Sono principi, piuttosto che chiedere ad un oggetto un suo campo privato per fare delle azioni bisogna dire all'oggetto fai questa azione per me.

Esempio:

Oggetto Impiegato, anziche' avere una God Class che raccoglie i dati da impiegato per fornire una visualizzazione via gui...

impiegatoRaoul.getName
impiegatoRaoul.getCognome
impiegatoRaoul.getCodiceFiscale

faccio questo impiegatoRaoul.displayInformazioniPersonali, se seguo la strada del get and set avro' una bella God class che
sicuramente colleghera' i dati ad un unica modalita' di presentazione di dati... (E se cambiabutto via tutto?)...

Allora non ci sto capendo nulla

riprendendo il tuo esempio:

impiegatoRaoul.getName <- questo sarà un metodo pubblico o sbaglio ?

[^TiGeRShArK^]

Originariamente inviato da RaouL_BennetH

Allora non ci sto capendo nulla

riprendendo il tuo esempio:

impiegatoRaoul.getName <- questo sarà un metodo pubblico o sbaglio ?

si ma lui sta parlando del caso specifico in cui devi usare il getter per prendere i dati dell'impiegato da visualizzare in una gui...