Newsgroup: it.comp.java
Titolo: Help metodi

Sapreste dirmi se un metodo di una classe puo' aggiornare un dato di un oggetto di un'altra classe....Mi sa che non sono stato molto chiaro   vediamo:
Io ho due classi diverse dalle quali creo due oggetti uno per ogni classe, e' possibile che in qualche modo uno dei due oggetti tramite magari un suo metodo possa cambiare un dato dell'altro oggetto e come?
bha provate a capirci qualche cosa io ormai non ci capisco piu' nulla!
Ciao Grazie.

Direi passando un riferimento all'oggetto aggiornabile all'apposito metodo dell'oggetto "aggiornante" :
Esempio :
// definizione classe aggiornabile
public class ClasseAggiornabile {
  String dato ;
  public void aggiornaDato (String nuovoDato) {
    this.dato = nuovoDato ;
  }
  public void stampaDato () { 
    System.out.println(dato) ;
  }
}
// definizione classe "aggiornante"
public class ClasseAggiornante {
  public void aggiornaClasseAggiornabile (ClasseAggiornabile a, String nuovoDato) {
    a.aggiornaDato(nuovoDato) ;
  }
}
// esempio di codice
ClasseAggiornabile a = new ClasseAggiornabile () ;
ClasseAggiornante  b = new ClasseAggiornante () ;
b.aggiornaClasseAggiornabile(a,"pippo") ;
a.stampaDato();  // dovrebbe stampare "pippo"
Ciao, Cris

-- 
Cristian Veronesi - CRPA SpA - Reggio Emilia, Italy
Whatever it is, I'm against it (Groucho Marx)

 Sapreste dirmi se un metodo di una classe puo' aggiornare un dato di un oggetto di un'altra classe
Beh ovviamente. Ci sono due modi:
1) Il modo da non seguire.
class A {
    public int valore;
}
class B {
    A a = new A();
    a.valore = 15;
}
2) Il modo da seguire (incapsulazione, java beans - approfondisci gli argomenti):
class A {
    private int valore;
    public void setValore(int nuovoVal) {
        valore = nuovoVal;
    }
class B {
    A a = new A();
    a.setValore(15);
}
--
Ciao,
 Stefano
----------
"X WindowSSS, teSSSoro mio... lo odieremo per SSSempre"
Bill Gollum
----------

 
BTW, questo concetto di incapsulamento, seppur diffusissimo, è molto
fragile e meriterebbe un bel thread a parte. Non basta l'indirezione di
un metodo per dire di non aver esposto la struttura della classe, anzi,
non cambia quasi niente. Tutto sta nel vedere se ha senso per la classe
in questione avere un metodo setter, ci potrebbe essere un modo diverso
di progettarla (ovviamente dipende dal contesto).
Ciao
-- 
Ugo
°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°
Enterprise Java Consulting
@mail: Ugo.L...@Flashnet.it
Home URL: 
http://www.ugolandini.net
Mentoring: 
http://www.projectoo.com
Sample Work: 
http://www.sirena.lomb.cgil.it
Work Phone: 02/61860647-6-4
Cell Phone: 0347/6310749 - 0347/4783580
Fax Phone: 02/700 413 187
°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°

 di progettarla (ovviamente dipende dal contesto).
Certo, però per un esempio può anche andare bene.


 °°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°
-- 


 
Certo che si, volevo solo aprire un altro thread (magari più
interessante), non criticare il tuo esempio...!!!


 interessante), non criticare il tuo esempio...!!!
Che c'entra, accetto anche le critiche! :)
Effettivamente però mi hai incuriosito, puoi indicarmi qualche link da
leggere al riguardo? L'incapsulazione mi interessa parecchio.
Ciao,
    Stefano

 
Beh, il discorso è lungo, comunque inizio io:
è ovvio che ripeterò qualche concetto già noto a (quasi) tutti, ma è
necessario farlo. Comunque il concetto di incapsulamento - come saprai -
è una "istanza" del concetto, più ampio, di "information hiding", ossia
nascondere l'informazione per permettere allo sviluppatore (A) di
cambiare del codice senza che l'"utente" del codice stesso (B, anch'esso
un programmatore) ne risenta. Nel caso specifico dell'incapsulamento,
questo vuol dire in pratica rendere privati gli attributi di una classe,
in modo che nessuno possa accedervi da un'istanza o da un sottotipo: in
questo modo la struttura interna della classe - cioè COME la classe è
fatta per funzionare - resta "nascosta" (hidden) e A può cambiarla a suo
piacimento. Se però l'interfaccia (l'insieme delle signature dei metodi
"pubblici" esposti, non necessariamente quella rappresentata dalla
keyword di Java) cambia, il povero B deve riscrivere tutti i suoi bei
programmi che fanno uso della classe in questione. Per questo si dice
che l'interfaccia è un contratto implicito che si stipula con gli utenti
della classe, e che non bisognerebbe mai "rompere". Alla luce di questo,
risulta ovvio che i metodi getter/setter "rompono" l'incapsulamento, in
quanto espongono chiaramente la struttura interna, come se gli attributi
fossero pubblici o poco meglio. Se dovesse cambiare la struttura
interna, dovrebbero facilmente cambiare anche le "signature" dei metodi
corrispondenti (se cambia l'implementazione del metodo invece è poco
importante, non fa parte del "contratto"), a meno di acrobazie varie, ed
il beneficio fondamentale della programmazione ad oggetti andrebbe
perso. Il livello di indirezione fornito dal metodo setter/getter non è
infatti sufficiente a "proteggere" il contratto stipulato con
l'interfaccia, ed è utile solo in caso di cambiamenti marginali. Basta
cambiare il tipo di un attributo (es. da int a String) ed il metodo
setter/getter deve necessariamente cambiare, rompendo il contratto e
costringendo B a riscrivere parte del suo codice.
Non c'è una soluzione "pronta" a tutto questo, ma si possono solo
indicare delle linee guida.
Bisogna progettare con accortezza le classi soprattutto facendo uso
delle interfacce (stavolta "fisiche", quelle di Java) che esplicitano
chiaramente il "contratto", altrimenti implicito, che si stipula con
l'utente della classe. Evitare di porre nelle interfacce metodi
getter/setter, a meno che non "ovvii e "naturali" per la classe
progettata, a costo di ripensare bene il tutto.
Evitare di istanziare direttamente l'oggetto utilizzando un handle della
classe, ma istanziarlo sempre tramite un handle di tipo "Interface" (Su
Design Patterns, il concerto viene indicato con "program to an interface
and not to a class").
In sostanza, una classe ben fatta avrà probabilmente degli attributi
utilizzati esclusivamente da metodi "privati", inizializzati dal
costruttore e non accessibili pubblicamente (neanche tramite metodi!).
Di contro, la sua interfaccia si concentrerà sui "servizi" che essa
offre, cercando di mantenere il punto di vista dell'utente della classe
e non dello sviluppatore. Questi metodi ovviamente lavoreranno sugli
attributi, ma non saranno una rappresentazione "diretta" dell'attributo
stesso, e modelleranno dei comportamenti, più "riutilizzabili". Se così
non fosse, non ci sarebbe quasi nessuna differenza fra una classe ed una
struct del c od un record del pascal.
Per finire (ma ci sarebbe molto altro da dire: standard di codifica,
fragile base class, ecc. ), quando si progettano della classi per prima
cosa bisogna vedere se ci sono delle soluzioni "standard" al problema,
dunque guardare nei cataloghi di Design patterns, dove si trovano
soluzioni a problemi tipici, con PRO e CONTRO in bella vista. Poi, sia
che si stia adattando una soluzione preesistente sia che si stia
creandone una tutta nuova, cercare di mantenere i due punti di vista
(sviluppatore e utilizzatore) contemporaneamente, magari facendo
"provare" la classe ad un altro programmatore e sentire cosa ne pensa,
tentando di immaginare usi ed abusi futuri della classe stessa. Una
piccola regola pratica potrebbe essere quella di progettare PRIMA
l'interfaccia della classe (cosa si vuole fare, che servizi deve
offrire), e solo POI implementarla, cercando per quanto possibile di
rispettare l'interfaccia. Io almeno seguo questo approccio, se ho poco
tempo magari solo mentalmente: mi piacerebbe avere una classe che faccia
questo, questo e quest'altro (l'interfaccia), astraendomi dagli
attributi necessari. E' ovvio che l'uso di un linguaggio di modellazione
come UML, che costringe a pensare prima di scrivere, aiuti molto in
questo approccio.
P.S. Il discorso dei Jsvabeans è un po' diverso: i metodi setter/getter
servono all'IDE per settare delle proprietà grafiche di un oggetto da
visualizzare nell'ambiente, personalizzabile dall'utente
Ciao


Ugo Landini wrote:
[SNIP]
Diem non perdidi! :)
Grazie Ugo, stanotte ci rimuginerņ sopra.
