[RISOLTO] Overload "Inverso" Java

[SuperStep]

Salve,

in java (come in altri) e' possibile definire piu' metodi con lo stesso nome, e chiamare il metodo "giusto" a seconda dei parametri...

io avrei la necessita' opposta, ovvero:
io ho lo stesso metodo con lo stesso numero di parametri, ma che restituiscono un tipo diverso...
come faccio a chiamare il metodo giusto a seconda del parametro che voglio?

Esempio:

Codice: Seleziona tutto

//#1
public Integer getObjectRandom(){
    ... someting ...
}

//#2
public String getObjectRandom(){
    ...someting...
}
...
Integer i = getObjectRandom(); //vorrei chiamare #1
String s = getObjectRandom(); //vorrei chiamare #2

esiste un modo?

[John_Marco]

Non puoi farlo. Citando dalla documentazione http://docs.oracle.com/javase/tutorial/ ... thods.html

Overloaded methods are differentiated by the number and the type of the arguments passed into the method. In the code sample, draw(String s) and draw(int i) are distinct and unique methods because they require different argument types.

You cannot declare more than one method with the same name and the same number and type of arguments, because the compiler cannot tell them apart.

The compiler does not consider return type when differentiating methods, so you cannot declare two methods with the same signature even if they have a different return type.

Una semplice alternativa per risolvere il tuo problema potrebbe essere quella di modificare con

Codice: Seleziona tutto

String getStringRandom () {// codice}
int getIntRandom () {//codice}

[SuperStep]

che peccato,

ti ringrazio per la risposta.

[John_Marco]

Figurati, nessun problema

[Zoff]

In realtà se usi l'inferenza di tipo dinamica, e qualche sotterfugio non proprio bellissimo puoi.
L'implementazione rimane sempre la stessa, ma il tipo del valore restituito può cambiare:

Codice: Seleziona tutto

public class MultipleReturnTypeExample {

	public static <T> T foo(Class<T> bar){
		if( String.class.isAssignableFrom(bar) ){
			return (T)"It works!!!";
		}
		if( Integer.class.isAssignableFrom(bar) ){
			return (T)new Integer(1);
		}
		throw new RuntimeException("Unsupported return type");
	}
	
	public static void main(String[] args) {
		int n = foo(Integer.class);
		System.out.println(n);
		String s = foo(String.class);
		System.out.println(s);
	}
}

È decisamente brutto, ma se proprio non puoi farne a meno...

[SuperStep]

In realtà se usi l'inferenza di tipo dinamica, e qualche sotterfugio non proprio bellissimo puoi.
L'implementazione rimane sempre la stessa, ma il tipo del valore restituito può cambiare:

Codice: Seleziona tutto

public class MultipleReturnTypeExample {

	public static <T> T foo(Class<T> bar){
		if( String.class.isAssignableFrom(bar) ){
			return (T)"It works!!!";
		}
		if( Integer.class.isAssignableFrom(bar) ){
			return (T)new Integer(1);
		}
		throw new RuntimeException("Unsupported return type");
	}
	
	public static void main(String[] args) {
		int n = foo(Integer.class);
		System.out.println(n);
		String s = foo(String.class);
		System.out.println(s);
	}
}

È decisamente brutto, ma se proprio non puoi farne a meno...

Beh, e' sicuramente meglio di nulla.... non sarei mai arrivato a questa soluzione.

[Zoff]

Beh il punto è che l'overload del valore restituto non dovrebbe mai servire.
Il modello dei dati deve essere costruito adeguatamente, se un tipo primitivo o della libreria standard non è sufficiente si crea un nuovo tipo di dato che abbia il comportamento desiderato.
A te perché servirebbe?

[SuperStep]

effettivamente potrei risolvere con nomi diversi, ma sostanzialmente e' questo:

ho un'interfaccia di nome Position, che serve a consultare gli elementi in quella posizione.

da position ho vari Nodi che implementano Position, che permettono di accedere ad altri elementi (es: Next, Prev, ...).

Vorrei che quando lo chiama qualcuno prenda il metodo public che restituisce position:

quando lo chiama l'oggetto che istanzia la classe prende il metodo protected che restituisce la classe che implementa position.

es:

Codice: Seleziona tutto

interface Position<E>{
    public element();
}

class NodePosition<E> implements Position<E>{
   ... element, ... next, ... prev
}

class NodePositionList<E> implements PositionList<E>{
    protected NodePosition<E> getPositionOf...(){
        ....
    }

    public Position<E> getPositionOf...(){
       ....
   }
}

avendo i nomi uguali mi risparmio un sacco di mal di testa, non effettuo casting, ed in piu' il metodo pubblico avrebbe restituito il protected senza fare altro, ma con l'interfaccia.

[Zoff]

Oddio, io avrei detto il contrario.
Hai due metodi che fanno cose semanticamente differenti che si chiamano allo stesso modo.

A me il mal di testa lo farebbe venire non evitare.
Soprattutto quando o vai a riprendere in mano dopo un po' che non lo usi.

[SuperStep]

no in realta' fanno la stessa cosa.

in realta' sarebbe quest:

Codice: Seleziona tutto

public Position<E> getPositionOf...(){
    return (Position<E>)this.getPositionOf...(); //chiama il metodo protected e restituisce il NodePosition castato a Position<E>
}

cosi' quando sono nella classe, ed ho bisogno di un nodo faccio:
NodePosition<E> node = getPositionOf...(); //prendo la NodePosition<E>

quando sono fuori dalla classe ed ho bisogno di una posizione faccio:
Position<E> node = getPositionOf...(); //prendo la Position<E>

[Zoff]

Scusa ma NodePosition è anche una Position, non capisco il problema.

[SuperStep]

se nella classe io faccio NodePosition<E> n = (NodePosition<E>) getPositionOf..();
non sto facendo due cast inutili?

cioe', l'oggetto non diventa prima da NodePosition -> Position -> NodePosition ?

inoltre, se supponendo, restituisca il Nodo di una Position differente, magari una cosa del genere?

Codice: Seleziona tutto

TreePosition<E> getPositionOf..(){ ... };

con TreePosition che implementa Position;

dovrei fare una cosa del genere ogni volta:

Codice: Seleziona tutto

try{
    NodePosition<E> n = getPositionOf...();
}
catch(ClassCastException e){
    try{
        TreePosition<E> n = getPositionOf...();
    }
    catch(ClassCastException e)
}

con il tipo di ritorno sarebbero i metodi diversi a scegliere la struttura da restituire (Un po come con argomenti diversi eseguo metodi diversi), allo stesso modo, potrei utilizzare una combinazione di strutture, e muovermi su queste con una Position, Ogni elemento potrebbe poi organizzare le stesse strutture in vari modi (Alberi, Liste, Ecc...), e modificare la struttura in base a come intendo muovermi.

Codice: Seleziona tutto

class PolymorphicStructure ... {
    NodePosition<E> getPositionOf...(){
        ... la struttura ora e una lista concatenata ...
    }

   TreePosition<E> getPositionOf...(){
      ... la struttura ora e' un albero ...
   }
}

ovviamente non voglio veramente realizzare una struttura polimorfica...

ma mi vengono in mente un paio di casi in cui questa policy si potrebbe applicare.

[Zoff]

Tu lavori sempre e comunque con Position, non ti è sufficiente?
non devi fare cast.

[SuperStep]

si ma ad esempio, l'unico metodo di position e': element().

mentre:
NodePosition implementa Next, Prev.
TreePosition implementa parent, childs, ...

[Zoff]

Ok, ma semanticamente getPositionOf ti da una Position.
Se fai restituire qualcosa di diverso cambia la semantica.
Inoltre per garantire il funzionamento i controlli li devi fare comunque, altrimenti ti ritrovi il programma che si aspetta una NodePosition che riceve una TreePosition e vs in RuntimeException, che è decisamente peggio.

[SuperStep]

si effettivamente mi sto complicando troppo la vita, per una cosa decisamente banale.

Ma mi allettava il fatto di poter fare la cosa adatta semplicemente con una Position, una cosa del tipo:

Codice: Seleziona tutto

public Position<E> getPositionOfFirstBigger(Position<E> p){
    BinaryTreePosition<E> p = getPositionOfThis(p); //ora ho un albero bilanciato dove l'elemento a destra e' il primo piu' grande
    if (p.right() != null) return p.right();
   else throw new NoBiggerElementThanThisException(...);
}

public Position<E> getPositionOfEquaslElement(Position<E> p){
    NodePosition<E> p = getPositionOfThis(p); //ora ho una lista ordinata;
   if(p.prev().element() == p.element()) return p.prev();
   if(p.next().element() == p.element()) return p.next();
   throw new NoMatchElementException(...);
}

e tutte le trasformazioni sono interne alla classe.

(Molto probabilmente e' ESTREMAMENTE pesante per via delle trasformazioni ogni volta, ma potrebbe servire in casi analoghi...)

[Zoff]

Non si tratta di pesantezza delle operazioni.
Se il metodo si chiama allo stesso modo il comportamento non è deterministico.
Pensa a questa assegnazione assolutamente lecita:

Codice: Seleziona tutto

Position<E> pos = getPositionOf( p );

Quale dei due dovresti richiamare?

[SuperStep]

in questo caso effettivamente non si puo' agire...

O almeno se non esiste un metodo che restituisce l'interfaccia.

[Zoff]

Non cambierebbe molto, per il compilatore tutti matcherebbero l'interfaccia e non saprebbe comunque quale utilizzare