Newsgroup: it.comp.java
Titolo: metodi che ritornano coppie (o n-uple)

Spesso mi capita di avere bisogno di ottenere due oggetti distinti
dallo stesso metodo
ad esempio, se dovessi scrivere il metodo divisioneTraInteri(Integer
dividendo, Integer divisore), avrei bisogno che ritornasse sia il
quoziente che il resto, come due interi separati.
Magari il mio stile di programmazione non è dei migliori, ma mi capita
spesso di dovre inserire tra le classi dei miei progetti, una cosa
come
public class Couple<X, Y> {
	public final X x;
	public final Y y;
	public Couple(X x, Y y) {
		this.x = x;
		this.y = y;
	}
}
e poi di abusare dei generics per ottenere un (IMHO brutto, ma meglio
che niente)
Couple<Integer, Integer> divisioneTraInteri(Integer dividendo, Integer
divisore) { ... }
piuttosto che quello che mi serve davvero.
Sono il solo a sentire quest'esigenza?
Sono solo cecato e ignorante, da non aver mai notato tra le librerie
standard di Java qualcosa del genere? (a volte mi sono messo ad usare
Map.Entry come surrogato di Couple, non ho mai trovato di meglio)

 Map.Entry come surrogato di Couple, non ho mai trovato di meglio)
Potresti restituire un array lungo a piacere.

 quoziente che il resto, come due interi separati.
  public class Divisione
   {
    public final int quoziente;
    public final int resto;
    public Divisione(int dividendo,int divisore)
     {
      quoziente=dividendo/divisore;
      resto=dividendo%divisore;
     }
   }
//......
Divisione d=new Divisione(10,3);
System.out.println("il risultato � "+d.risultato);
System.out.println("il resto � "+d.resto);

 
Perch� non ti fai ritornare un bel bean con le propriet� che ti servono?
E usiamoli sti oggetti. :-)
es
public class Divisione{
....
   public RisultatoDivsione divisioneTraInteri(int a,int b){
	....
   }
}
dove RisultatoDivisione �
public class RisultatoDivisione extends RisultatoOperazione{
 
	//il risutato intero � contenuto nella superclasse
        protected int resto;
}
Spero di essere stato di aiuto.

 
In effetti delle volte l'esigenza di avere un "ennupla" di valori si 
sente. Certo col bean risolvi, ma, penso che si possa ritenere 
"eccessivo" fare una classe solo per tenermi dentro due interi.
Nel corso del tempo ho usato diverse alternative (finendo poi quasi 
sempre per 'fare il bravo' e fare la classe apposita, per la verit�)
Principalmente alla fine l'unica alternativa pi� o meno valida di quelle 
che ho incontrato � usare un array o un List, il problema � che se non 
hai oggetti dello stesso tipo (che so, un Integer e un BigDecimal) ti 
tocca usare un array di Object, e si perde un po' il senso della cosa.
Per una ennupla di oggetti della stessa classe, pu� avere un senso. Per 
far meglio, ci vorrebbero delle classi TPla<T> che ti forniscano qualche 
metodo di supporto (ci sono? qualche libreria matematica? o son troppo 
simili a List?)
-- 
bye
DKano

 "eccessivo" fare una classe solo per tenermi dentro due interi.
IMHO qualsiasi altra soluzione � peggiore.
Inoltre perch� mai dovrebbe essere eccessivo?
Diciamo che una classe Pair<S, T> dovrebbe essere inserita nella 
libreria standard di Java, ma per qualche stupida ragione non � stato 
fatto (forse perch� solo con i generics questa classe ha un certo senso).
Magari la inseriranno in futuro...

 
Beh dipende dal contesto nel quale si � calati, ovviamente se i due 
interi li devi usare in punti diversi personalmente preferisco un bean 
(sono un programmatore old style), soluzione che � pi� immediata anche 
per chi si accinge a leggere il nostro codice. Concordo che il mio 
esempio era un tantino esagerato (il bean estendeva da una una 
superclasse) ma � stato preso al volo da una slide che utilizzo per 
spiegare il polimorfismo.
gm.

 Map.Entry come surrogato di Couple, non ho mai trovato di meglio)
Se sono valori dello stesso tipo un array altrimenti un bean.

 Magari la inseriranno in futuro...
Ehm... scusate... c'ï¿œ qualcosa che vieta di usare
java.util.AbstractMap.SimpleEntry ?
Anche se un po' "sepolta", ï¿œ una classe pubblica e perfettamente
utilizzabile. Cosa ne dite?
-- 
Scientology: se la conosci la eviti, se la conosci non ti uccide...
http://xenu.com-it.net
 - 
http://xenu.freewinds.cx
 - 
http://www.xenu.net
(per rispondere personalmente leva IlDitoDalCulo)
---> 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 <---

 Magari la inseriranno in futuro...
Infatti mi chiedevo quale fosse la stupida ragione. Non vorrei che 
qualcuno avesse tirato fuori qualche ragione filosofica per non 
introdurle (a mio parere le 'ragioni filosofiche' sono quanto di pi� 
dannoso ci sia nell'informatica, vedi per esempio ant senza istruzioni 
per i cicli, ma questo � un altro discorso) oppure qualche ragione 
pratica di qualche genere. Per la verit� pi� che un Pair<S,T> ci 
vorrebbe una TPla<A,B,...> ma non so se attualmente sia possibile 
definire qualcosa con un numero variabile di valori dentro le "<>". 
Forse alla fine han deciso che si sopperisce con un list/array nella 
maggior parte dei casi e che il gioco non vale la candela?
-- 
bye
DKano

 essere eccessivo?
in effetti definire un tipo statico apposta, quindi scrivere codice, per 
una esigenza estemporanea di un ritorno di un metodo è un po' eccessivo.

Va bene il tuo metodo
