Newsgroup: it.comp.java
Titolo: Collections come parametri

Una domanda filosofica.
Sappiamo come gli oggetti vengono passati ai parametri dei metodi 
(tranquilli, non voglio avviare l'ennesima discussione 
reference/puntatori/etc...).
Sappiamo anche che se passo una collection come parametro ad un metodo, 
quest'ultimo ne può modificare il contento.
La questione è nata allorchè stavo scrivendo un metodo del genere:
protected String getInsertStatement(List columns, List parameters)
{
[...]
}
Il metodo restituisce una stringa, ma popola 'parameters' con la lista 
dei parametri richiesti dallo statement. In pratica, il succo è che il 
metodo ha bisogno di avere due oggetti di ritorno, una stringa e una 
lista di parametri.
E' chiaro che così funziona. Però devo dire che non ho esempi di design 
(fra le API e svariate librerie) in cui viene usato la tecnica che, in 
altri linguaggi, verrebbe chiamata "restituire un oggetto tramite 
parametro per reference".
Cosa ne pensate?

"Vincent Vega":
| 
| Il metodo restituisce una stringa, ma popola 'parameters' con la lista 
| dei parametri richiesti dallo statement. In pratica, il succo è che il 
| metodo ha bisogno di avere due oggetti di ritorno, una stringa e una 
| lista di parametri.
E se il tuo metodo, invece di essere di tipo String fosse di tipo 
Vector? Potresti far restituire la stringa come primo elemento e la 
lista dei parametri come secondo elemento.
O forse ho capito male quello che volevi dire?
-- 
da. 

Non so se ho colto il senso della domanda, ma credo che tu cxerchi nelle api
un esempio di un design analogo al tuo, che usa cioč un parametro come
contenitore per l'output del metodo. Se č cosě, mi pare ci sia una cosa
analoga nelle api di stampa: chiami un metodo del printJob che accetta un
pageformat (che contiene le impostazione della pagina di stampa) e pare una
finestra di dialogo dalla quale si possono impostare tali opzioni; quando
chiudi la finestra il pageformat che gli hai passato risulta aggiornato. Il
metodo non restituisce direttametne il pageformat perchč restituisce invece
un int che indica se la finestra č stata chiusa con il pulsante ok o
annulla...
Ciao
Giacomo

 lista di parametri.
A me non piace questo approccio misto, cioé o modifichi i parametri (e
allora il metodo è void) o restituisci qualcosa. In particolare, se
modifichi i parametri deve essere chiaro perché un client di quel metodo
potrebbe non aspettarselo e sarebbero guai ;)
D'altra parte nemmeno mischiare i risultati mi sembra una buona soluzione
(tipo, già che devi restituire una lista, buttaci dentro pure la stringa).
Secondo me la cosa migliore è una classe, direi meglio se annidata in quella
che contiene il metodo, per rappresentare l'aggregato dei dati da
restituire.
Nel tuo esempio:
public class InsertResult {
 private String s;
 private List l;
  public InsertResult(String str, List list) {
     s = str;
     l = list;
  }
  public String getString() {
     return s;
  }
 
  public List getList() {
    return l;
  }
}
protected IsertResult getInsertStatement(List columns, List parameters)
{
[...]
}
Ciao
-- 
chi sono e soprattutto chi non sono:
http://www.ilnomedeldominio.it
un piccolo programma per studenti universitari:
http://inutility.ilnomedeldominio.it

 O forse ho capito male quello che volevi dire?
Diciamo che questa potrebbe essere una soluzione.
Ma più che altro, volevo capire se in java era considerato un design
corretto far restituire dei dati ad un metodo attraverso i parametri
(come avviene spesso in C/C++, per esempio).
Di solito per capire se un design è corretto in java mi riferisco a
implementazioni analoghe nelle API (quando ovviamente non mi posso
riferire ad un pattern). Se ci sono, mi tranquillizzo :-)

 annulla...
Esatto, e questo sarebbe un classico esempio di design che ho
utilizzato piů volte in altri linguaggi: il metodo (o la funzione)
resituisce un codice di errore (magari il classico 1 ok, -1 errore, 0
nulla di fatto), mentre il risultato vero e proprio dell'elaborazione
č contenuto in un oggetto passato come parametro.

 è contenuto in un oggetto passato come parametro.
Se quello che devi restituire è un codice di errore forse è più corretto
utilizzare un'eccezione.
Però deve essere un codice di errore e non uno "stato di elaborazione".
Nel tuo caso non penso che 0="nulla di fatto" sia un codice di errore
(a meno che tu non voglia che sia gestito come una soluzione anomala).
In ogni caso io non farei mai ritornare -1 per segnalare l'errore ma
utilizzerei comunque un'eccezione, obbligando a gestire la situazione
anomala. Uno si può dimenticare di controllare un codice d'errore,
molto più difficile che si dimentichi di gestire un'eccezione (lo
obbliga il compilatore).
Andrea Polci
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 utilizzare un'eccezione.
In realtà il metodo originale restituisce una stringa con una sintassi 
SQL, più una List dei parametri nell'ordine in cui devono essere 
sostituiti con PrepareStatement.
La sintassi viene restituita nel valore di ritorno, per i parametri 
viene popolata una List passata come parametro.