|
|||||||
|
|
|
![]() |
|
|
Strumenti |
|
|
#1 |
|
Senior Member
Iscritto dal: Aug 2005
Messaggi: 439
|
[java] override metodi
__________________
my pc :core duo2 e8500 ,asus rampage formula,corsair dominator 4giga, sapphire ati4870 512mb monitor samsung 22" t220hd vista 32bit Nel corso della vita, non ci sarà certo penuria di gente che ti dice come vivere, avranno tutte le risposte, cosa dovresti fare, cosa non dovresti fare. Non ci discutere mai, tu di' sempre: «Ah sì? è un'idea davvero brillante» e poi fai come ti pare.(Woody Allen) |
|
|
|
|
|
#2 |
|
Senior Member
Iscritto dal: Nov 2004
Città: Tra Verona e Mantova
Messaggi: 4553
|
Non c'è sovrascrittura di metodi in quel diagramma. C'è invece sovraccaricamento (metodo con lo stesso nome ma lista di parametri diversa).
__________________
Uilliam Scecspir ti fa un baffo? Gioffri Cioser era uno straccione? E allora blogga anche tu, in inglese come me! |
|
|
|
|
|
#3 |
|
Senior Member
Iscritto dal: Aug 2005
Messaggi: 439
|
Come posso fare allora per definire il metodo press per ogni sottoclasse?
__________________
my pc :core duo2 e8500 ,asus rampage formula,corsair dominator 4giga, sapphire ati4870 512mb monitor samsung 22" t220hd vista 32bit Nel corso della vita, non ci sarà certo penuria di gente che ti dice come vivere, avranno tutte le risposte, cosa dovresti fare, cosa non dovresti fare. Non ci discutere mai, tu di' sempre: «Ah sì? è un'idea davvero brillante» e poi fai come ti pare.(Woody Allen) |
|
|
|
|
|
#4 |
|
Senior Member
Iscritto dal: Jul 2006
Città: Tristram
Messaggi: 517
|
Per override si intende definire un metodo con la stessa signature (ovvero nome e parametri in ingresso) della classe madre.
Quindi ti basta definire nelle classi figlie lo stesso IDENTICO metodo (in termini di signature ovviamente, il corpo sarà diverso, altrimenti non avrebbe senso ridefinirli) della classe madre, ovvero press()
__________________
Il sole è giallo |
|
|
|
|
|
#5 | |
|
Senior Member
Iscritto dal: Nov 2004
Città: Tra Verona e Mantova
Messaggi: 4553
|
Quote:
Codice:
class A {
void metodo(Object arg) {
System.out.println("object");
}
}
class B {
void metodo(String arg) {
System.out.println("string");
}
}
A a = new B();
a.metodo("hello world");
Ciò avviene perchè la risoluzione del nome del metodo da invocare è determinata a tempo di compilazione in base ai metodi disponibili nel tipo in compilazione. A.metodo(una stringa) diventa il metodo(Object) dichiarato in A (ed esteso in B) perchè A non dichiara un metodo(String). Una soluzione è: Codice:
class Bottoni {
void press(Object arg) {}
void press(char c) {}
void press(int i) {}
void press(String s) {}
}
class BottoniAlfabetici {
void press(char c) {}
}
class BottoniNumerici {
void press(int i) {}
}
class BottoniOperazioni {
void press(String s) {}
}
Bottoni x = new BottoniAlfabetici(); x.press(10); //-> invoca la definizione di press(int) data in BottoniAlfabetici Esistono alternative più esotiche, ad esempio una mappa di funtori, o esoteriche, vale a dire l'invocazione riflessiva di metodi. La prima cambia il design della tua gerarchia di tipi, la seconda non è neppure esprimibile in un diagramma di classi UML riferito a Java
__________________
Uilliam Scecspir ti fa un baffo? Gioffri Cioser era uno straccione? E allora blogga anche tu, in inglese come me! |
|
|
|
|
|
|
#6 |
|
Senior Member
Iscritto dal: Sep 2003
Città: Milano
Messaggi: 4623
|
meglio lavorare con un interfaccia implementata da una classe delegate che si preoccupa di istanziare la classe giusta / il metodo giusto attraverso il pattern factory.
(se poi dovrai modificare qualcosa o aggiungere nuove implementazioni del metodo non dovrai modificare l'interfaccia, ma solo aggiungere una nuova classe e modificare il factory, disaccoppiando il resto dalle tue classi)
__________________
Ho trattato con : lahiri, czame, RC, allXXX, dfruggeri, JMM, Paperone, xej, Pappez, iperfly, Red81, Playmake, ryan78, Rob66, XP2200, Peach1200, faberjack, Stewie82, supermario_bros, hft500, Axelscorpio, pipes lee, Piccolospazio, RohanKish, miki66, kabira85 |
|
|
|
|
|
#7 |
|
Senior Member
Iscritto dal: Nov 2004
Città: Tra Verona e Mantova
Messaggi: 4553
|
E come risolvi il problema dell'invocazione dinamica di un metodo sovraccaricato?
__________________
Uilliam Scecspir ti fa un baffo? Gioffri Cioser era uno straccione? E allora blogga anche tu, in inglese come me! |
|
|
|
|
|
#8 | |
|
Senior Member
Iscritto dal: Sep 2003
Città: Milano
Messaggi: 4623
|
Quote:
cmq nel disegno il problema è che il metodo deve avere la stessa segnatura. al massimo wrappi il parametro in ingresso
__________________
Ho trattato con : lahiri, czame, RC, allXXX, dfruggeri, JMM, Paperone, xej, Pappez, iperfly, Red81, Playmake, ryan78, Rob66, XP2200, Peach1200, faberjack, Stewie82, supermario_bros, hft500, Axelscorpio, pipes lee, Piccolospazio, RohanKish, miki66, kabira85 |
|
|
|
|
|
|
#9 |
|
Senior Member
Iscritto dal: Nov 2004
Città: Tra Verona e Mantova
Messaggi: 4553
|
In pratica ad un certo punto sei costretto ad una conversione esplicita.
Rinunciare al typesystem non è una buona idea. Tanto varrebbe usare uno script e rischiare di spararsi nei piedi ogni due enunciati. Non che l'interfaccia sia una brutta idea, anzi. Bottone grida "interfaccia" in ogni direzione. Le factory poi in Java sono come la manna: risolvono il problema dei costruttori che non restituiscono istanze. Qui il problema però è che A.press(T) è supposto covariante in B.press(V) per ogni B <: A e T <: V. Mentre in Java è invariante. Tra l'altro forse il problema è questo. Non ho ancora saputo se l'intenzione implicita è poter dire: Bottone x = new BottoneNumerico(); x.press(10); e non ottenere un lamento dal compilatore o se il problema sia un altro.
__________________
Uilliam Scecspir ti fa un baffo? Gioffri Cioser era uno straccione? E allora blogga anche tu, in inglese come me! Ultima modifica di PGI-Bis : 03-04-2009 alle 18:38. Motivo: "supporto covariante" non aveva un gran senso :D. |
|
|
|
|
| Strumenti | |
|
|
Tutti gli orari sono GMT +1. Ora sono le: 04:52.





















