View Full Version : [Generico/OOP]Ereditarietà
RaouL_BennetH
30-03-2009, 14:08
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 :D
Grazie mille come sempre.
RaouL.
^TiGeRShArK^
30-03-2009, 14:28
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 :D
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
30-03-2009, 15:09
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^
30-03-2009, 15:12
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 :D 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. :p
cmq anch'io sono assolutamente a favore dell'uso delle interfacce. :D
RaouL_BennetH
30-03-2009, 15:33
Innanzitutto grazie per le risposte.
Ma quindi, se non ho capito male, la mia classe base dovrebbe essere un'interfaccia?
mindwings
30-03-2009, 15:37
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. :p
cmq anch'io sono assolutamente a favore dell'uso delle interfacce. :D
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:D
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...:doh:
mindwings
30-03-2009, 15:48
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
30-03-2009, 16:07
"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 :D
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
30-03-2009, 16:57
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
30-03-2009, 17:06
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 :D
Già stavo pensando all'incapsulamento della mia classe base ...... :muro:
[...] "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...:doh:
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 :D.
^TiGeRShArK^
30-03-2009, 23:47
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 :D.
ehmmm...
così fungono in realtà quelli automatici...
public class Person
{
public string Name { get; set; }
public int Age { get; set; }
}
:p
RaouL_BennetH
31-03-2009, 10:02
Visto che l'avete tirato in ballo (il C# intendo...)
non è quindi una buona pratica di programmazione utilizzare delle proprietà mediante get e set ??
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
31-03-2009, 10:47
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
31-03-2009, 10:54
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 cambia:confused:butto via tutto?)...
mindwings
31-03-2009, 10:59
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 :D.
Zuccherino sintattico?! :fagiano:
RaouL_BennetH
31-03-2009, 11:23
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 cambia:confused:butto via tutto?)...
Allora non ci sto capendo nulla :(
riprendendo il tuo esempio:
impiegatoRaoul.getName <- questo sarà un metodo pubblico o sbaglio ?
^TiGeRShArK^
31-03-2009, 11:51
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...
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 cambia:confused:butto via tutto?)...
Io metterei SIA i get SIA il display, ed userei i get all'interno di display.
Così se devi cambiare qualcosa sei in una botte di ferro :D
In più l'esempio è pessimello, perchè per quanto comodo la classe Impiegato non appartiene minimamente all'ambito UI (http://en.wikipedia.org/wiki/Aspect-oriented_programming)... e pertanto non ha senso che abbia un metodo per disegnare se stesso.
in effetti la cosa più corretta sarebbe proprio fare una classe esterna con un metodo Classe::display(Impiegato*).
Sarebbe una god class, ma questo non è un problema della programmazione ad oggetti, è un problema dell'informatica, dato che l'UI è per forza una sola cosa che fa tutto :asd:
E non credo che spargere la funzionalità di display dappertutto nel programma migliori la situazione.
Per evitare che in futuro tu debba scombinare tutto, basta rendere Classe sottoclasse di una interfaccia Displayer, così puoi cambiare modo di presentazione anche a runtime.
RaouL_BennetH
31-03-2009, 11:59
si ma lui sta parlando del caso specifico in cui devi usare il getter per prendere dei dati da visualizzare in una gui...
ah, non avevo capito.
volendo fare un mio esempio:
public class Azienda
{
private string name;
//proprietà
public string Name
{
get { return name }
set { name = value; }
}
//metodi classici
public string getName()
{
return name;
}
public void setName(string name)
{
this.name = name;
}
}
Sono confuso quindi su quale sia preferibile e perchè :)
Grazie.
RaouL.
E' precisamente la stessa cosa :asd:
Il primo è solo "syntactic sugar" per scrivere in breve gli altri due, per cui puoi scegliere quello che preferisci...
In genere per giustificare quella notazione andrebbero fatti dei controlli aggiuntivi, altrimenti c'è la notazione breve come Tiger ha giustamente riportato.
Ad esempio se ho un campo età potrei volerlo definire in un intervallo preciso e quindi il setter avrebbe il compito di fare anche quei controlli.
Non so, io trovo molto più elegante questa soluzione che usare un metodo, chiaramente il risultato è lo stesso, però così non riempi il codice di metodi get/set.
RaouL_BennetH
31-03-2009, 15:12
In genere per giustificare quella notazione andrebbero fatti dei controlli aggiuntivi, altrimenti c'è la notazione breve come Tiger ha giustamente riportato.
Ad esempio se ho un campo età potrei volerlo definire in un intervallo preciso e quindi il setter avrebbe il compito di fare anche quei controlli.
Non so, io trovo molto più elegante questa soluzione che usare un metodo, chiaramente il risultato è lo stesso, però così non riempi il codice di metodi get/set.
....
:)
Sono sempre più confuso :muro:
Non riesco a capire se sono questioni di stile o di efficienza vera e propria.
Addirittura stavo leggendo l'articolo presente qui:
http://www.hwupgrade.it/articoli/software/2170/ivar-jacobson-ecco-cosa-non-insegnano-ai-programmatori_index.html
e sono sempre più confuso.... da una parte si dice una cosa, da altre l'esatto contrario :D
^TiGeRShArK^
31-03-2009, 15:25
....
:)
Sono sempre più confuso :muro:
Non riesco a capire se sono questioni di stile o di efficienza vera e propria.
Addirittura stavo leggendo l'articolo presente qui:
http://www.hwupgrade.it/articoli/software/2170/ivar-jacobson-ecco-cosa-non-insegnano-ai-programmatori_index.html
e sono sempre più confuso.... da una parte si dice una cosa, da altre l'esatto contrario :D
il getters e il setters è buona norma metterli SEMPRE su classi abbastanza complesse per campi che è necessario rendere visibile dall'esterno, perchè in caso si rendano necessarie delle modifiche a come devo essere esposti qui dati all'esterno si può intervenire direttamente da questi metodi.
Se hai una certa esperienza, se sei pienamente consapevole di quello che stai facendo, e per classi piccole e che sai già esattamente come saranno usate, puoi anche fregartene ed esporre direttamente i campi, anche se non ho mai visto una sola persona che lo consigli. :asd:
e sono sempre più confuso.... da una parte si dice una cosa, da altre l'esatto contrario :D
Hai tutta la mia solidarietà. :mano:
mindwings
31-03-2009, 15:33
Io metterei SIA i get SIA il display, ed userei i get all'interno di display.
Così se devi cambiare qualcosa sei in una botte di ferro :D
In più l'esempio è pessimello, perchè per quanto comodo la classe Impiegato non appartiene minimamente all'ambito UI (http://en.wikipedia.org/wiki/Aspect-oriented_programming)... e pertanto non ha senso che abbia un metodo per disegnare se stesso.
in effetti la cosa più corretta sarebbe proprio fare una classe esterna con un metodo Classe::display(Impiegato*).
Sarebbe una god class, ma questo non è un problema della programmazione ad oggetti, è un problema dell'informatica, dato che l'UI è per forza una sola cosa che fa tutto :asd:
E non credo che spargere la funzionalità di display dappertutto nel programma migliori la situazione.
Per evitare che in futuro tu debba scombinare tutto, basta rendere Classe sottoclasse di una interfaccia Displayer, così puoi cambiare modo di presentazione anche a runtime.
L'esempio e' volutamente semplice... Impiegato puo' sempre delegare la visualizzazione ad altri:D
Dipende da quello che si vuole realizzare...
Principi OODesign da zio Bob :D -> http://www.butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod
mindwings
31-03-2009, 15:43
ah, non avevo capito.
volendo fare un mio esempio:
public class Azienda
{
private string name;
//proprietà
public string Name
{
get { return name }
set { name = value; }
}
//metodi classici
public string getName()
{
return name;
}
public void setName(string name)
{
this.name = name;
}
}
Sono confuso quindi su quale sia preferibile e perchè :)
Grazie.
RaouL.
Ha senso mettere il campo private se dopo gli dai i metodi di accesso e modifica get e set pubblici? a questo punto puoi definire il campo come
public....Stai usando un oggetto solo come contenitore di dati, dovresti
dare importanza al comportamento. Chiediti cosa deve fare il tuo oggetto?
Quali sono le sue responsabilita'?
banryu79
31-03-2009, 15:51
Ha senso mettere il campo private se dopo gli dai i metodi di accesso e modifica get e set pubblici? a questo punto puoi definire il campo come
public....Stai usando un oggetto solo come contenitore di dati, dovresti
dare importanza al comportamento. Chiediti cosa deve fare il tuo oggetto?
Quali sono le sue responsabilita'?
Il fatto è che ADESSO lo stai usando così però potrebbe succedere che DOMANI invece tu debba fare quel "qualcosina in più" in fase di modifica del valore di un campo.
Quindi: se ci accedi direttamente senza un setter (non il cane) da altre classi in caso di modifica dovrai andare a toccare tutti i punti in cui altro codice accede quel campo; con il setter (il cane è il migliore amico dell'uomo) invece puoi implementare le modifiche solo nel corpo del metodo.
Esempio ingenuo lo so :)
mindwings
31-03-2009, 19:35
Il fatto è che ADESSO lo stai usando così però potrebbe succedere che DOMANI invece tu debba fare quel "qualcosina in più" in fase di modifica del valore di un campo.
Quindi: se ci accedi direttamente senza un setter (non il cane) da altre classi in caso di modifica dovrai andare a toccare tutti i punti in cui altro codice accede quel campo; con il setter (il cane è il migliore amico dell'uomo) invece puoi implementare le modifiche solo nel corpo del metodo.
Esempio ingenuo lo so :)
Si ma la sostanza non cambia... Usare gli oggetti significa fare ASTRAZIONE, non bisogna esporre all'esterno i dettagli del suo funzionamento... Altrimenti che astrazione e'? Semplicemente un accrocchio di dati che incapsuliamo in un contenitore...
http://users.ipa.net/~dwighth/smalltalk/byte_aug81/design_principles_behind_smalltalk.html
Cito alcuni punti:
A system should be built with a minimum set of unchangeable parts; those parts should be as general as possible; and all parts of the system should be held in a uniform framework.Modularity: No component in a complex system should depend on the internal details of any other component.A program should specify only the behavior of objects, not their representation.
Why Getter and Setter methods are evil (dallo stesso autore del libro che ho citato prima)->
http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html
RaouL_BennetH
31-03-2009, 22:57
Perdonatemi lo sfogo dopo una giornata passata a cercare di scrivere qualcosa di funzionante... tra mille dubbi, cambi di passo, ripensamenti etcetera.... dico solo che sembra quasi che ci siano soltanto molti modi di fare la stessa cosa, ovvero, complicarsi inutilmente la vita perdendo di vista il risultato finale, ovvero_2_la_vendetta, un programma che funziona senza troppe pippe mentali :D
Chiedo ancora scusa per lo sfogo ma lo stato di confusione è ai massimi livelli :(
^TiGeRShArK^
01-04-2009, 00:18
Perdonatemi lo sfogo dopo una giornata passata a cercare di scrivere qualcosa di funzionante... tra mille dubbi, cambi di passo, ripensamenti etcetera.... dico solo che sembra quasi che ci siano soltanto molti modi di fare la stessa cosa, ovvero, complicarsi inutilmente la vita perdendo di vista il risultato finale, ovvero_2_la_vendetta, un programma che funziona senza troppe pippe mentali :D
Chiedo ancora scusa per lo sfogo ma lo stato di confusione è ai massimi livelli :(
KISS (http://en.wikipedia.org/wiki/KISS_principle).
Se non tieni d'occhio questo semplice e basilare principio non combinerai mai nulla di buono. ;)
Le seghe mentali lasciale per dopo, casomai ti resta tempo. :p
ah...
e ovviamente non dimenticare l'altrettanto importante YAGNI (http://en.wikipedia.org/wiki/You_Ain%27t_Gonna_Need_It). :D
mindwings
01-04-2009, 09:17
Perdonatemi lo sfogo dopo una giornata passata a cercare di scrivere qualcosa di funzionante... tra mille dubbi, cambi di passo, ripensamenti etcetera.... dico solo che sembra quasi che ci siano soltanto molti modi di fare la stessa cosa, ovvero, complicarsi inutilmente la vita perdendo di vista il risultato finale, ovvero_2_la_vendetta, un programma che funziona senza troppe pippe mentali :D
Chiedo ancora scusa per lo sfogo ma lo stato di confusione è ai massimi livelli :(
Se e' un programmino semplice e non un sistema allora tutte le seghe mentali non hanno senso, in ogni caso fai cio' che riesci a fare e approfondisci l'argomento sull'OOP se ti interessa.
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.