[JAVA] Array come elemento di una collection

[andbin]

Domanda veloce su una questione che mi sta confondendo un po': in Java è possibile usare un array come elemento di una collection???
Una cosa del tipo:

HashMap<String,Object> map = new HashMap<String,Object>();

int[] arr1 = { 1, 2, 3 };

map.put ("arr1", arr1);

Questo codice compila ok. E poi per estrarre l'array???
Ho provato:

int[] arr_out = map.get ("arr1");

ma mi da errore in compilazione.

[Angus]

Originariamente inviato da andbin

Domanda veloce su una questione che mi sta confondendo un po': in Java è possibile usare un array come elemento di una collection???
Una cosa del tipo:

HashMap<String,Object> map = new HashMap<String,Object>();

int[] arr1 = { 1, 2, 3 };

map.put ("arr1", arr1);

Questo codice compila ok. E poi per estrarre l'array???
Ho provato:

int[] arr_out = map.get ("arr1");

ma mi da errore in compilazione.

Stai dichiarando la tua mappa come accettante valori di tipo Object, quindi il metodo get restituisce riferimenti di tipo Object che ovviamente non puoi assegnare senza un cast esplicito a variabili dichiarate diversamente.

[andbin]

Originariamente inviato da Angus

Stai dichiarando la tua mappa come accettante valori di tipo Object, quindi il metodo get restituisce riferimenti di tipo Object che ovviamente non puoi assegnare senza un cast esplicito a variabili dichiarate diversamente.

Che scemo (che sono) ... è vero!! Un array è-un Object e quindi devo fare il cast esattamente come se avessi messo una String dentro una collezione di Object.
Anzi posso anche fare così:

Object o = map.get ("arr1");

if (o instanceof int[])
{
    int[] arr = (int[]) o;
    ....
}

[Angus]

Oppure dichiarare la mappa come <String, int[]>

[andbin]

Originariamente inviato da Angus

Oppure dichiarare la mappa come <String, int[]>

Sì, certamente!!! Però io avevo bisogno di una collezione (una Map è proprio quello che mi serve) in cui poter mettere insieme diversi tipi di cose come ad esempio valori Integer, Double, String e array di int o di double.

[luxorl]

Originariamente inviato da andbin

Sì, certamente!!! Però io avevo bisogno di una collezione (una Map è proprio quello che mi serve) in cui poter mettere insieme diversi tipi di cose come ad esempio valori Integer, Double, String e array di int o di double.

In questo caso la problematica a cui devi stare un po' attento è che quando tiri fuori gli oggetti il casting è diverso per ogni tipo di oggetto che tiri fuori.

[Angus]

Originariamente inviato da andbin

Sì, certamente!!! Però io avevo bisogno di una collezione (una Map è proprio quello che mi serve) in cui poter mettere insieme diversi tipi di cose come ad esempio valori Integer, Double, String e array di int o di double.

Non riesco proprio a trattenere la curiosità e devo chiederti di spiegare, se possibile, il perchè della necessità di un contenitore di oggetti eterogenei di cui non puoi estrapolare un insieme di caratteristiche comuni. Ho il sospetto che questa soluzione puzzi di cattivo design. Non è un'accusa, è solo che nella mia piccola esperienza non ho mai avuto il bisogno di fare una cosa del genere e quindi sono curioso.

[andbin]

Originariamente inviato da Angus

Non riesco proprio a trattenere la curiosità e devo chiederti di spiegare, se possibile, il perchè della necessità di un contenitore di oggetti eterogenei di cui non puoi estrapolare un insieme di caratteristiche comuni. Ho il sospetto che questa soluzione puzzi di cattivo design. Non è un'accusa, è solo che nella mia piccola esperienza non ho mai avuto il bisogno di fare una cosa del genere e quindi sono curioso.

Certo, te lo spiego subito! Così mi puoi dare magari un tuo parere e anche, eventualmente, un consiglio.

Devo implementare un sistema per passare dei dati (parametri) da una applicazione "C" ad una Java. L'applicazione C è molto grossa ed è sviluppata sia da me (in parte minore) che da altre persone. L'applicazione Java la sto sviluppando adesso io da zero.

Tutte le specifiche me le sto "inventando" io, quindi posso fare un po' come mi pare . Ogni parametro è una associazione nome->valore. I tipi che vorrei gestire, almeno al momento, sono: stringhe, interi, double. Per ognuno di questi tipi posso avere un valore scalare o un array (1 o 2 dimensioni).

Per quanto riguarda il passaggio fisico dei dati, ho pensato di usare un file XML del tipo:

<?xml version='1.0' encoding='iso-8859-1'?>
<parameters>
  <parameter type="string" name="nome1" value="aaaa" />

  <parameter type="int[2][2]" name="nome2">
    <values>
      <values>
        <value>123</value>
        <value>456</value>
      </values>
      <values>
        <value>1111</value>
        <value>4444</value>
      </values>
    </values>
  </parameter>
</parameters>

A parte tutta la questione del parsing del file (che non è difficile) alla "fine della fiera" ho poi un oggetto che chiamerò ParametersMap che contiene un TreeMap (ma se non ho bisogno di avere le chiavi ordinate dovrebbe bastare anche un HashMap).
Questa Map ha quindi delle stringhe come chiave e poi ..... direi un Object come valore.
Questo perché dentro posso avere una String, un Integer (che poi converto in int), un Double (che poi converto in double) o un int[], double[][], ecc....

Ti sembra buona come idea o no??? Nel caso non sia una buona idea, cosa sarebbe meglio fare??

[Angus]

Scusa se rispondo solo adesso. Per come hai esposto il problema direi che non ci sono elementi sufficienti per affermare che il design non è buono... però immagino che ci sia ben più semantica di così.
Per quanto riguarda il formato dell'XML può andare bene, visto che apparentemente non ci sono vincoli.
Non conoscendo l'utilizzo e l'utilizzatore di questi 'parametri', non posso suggerire miglioramenti, se non l'adozione di un'altro tipo di collezione: un'implementazione di List<Parameter>, dove Parameter è un'interfaccia (parametrica?) col metodo getValue().
Questo porterebbe qualche vantaggio anche in fase di progettazione del parser stesso: si potrebbe pensare ad una architettura a plugin dove hai un engine di parsing che si limita a riconoscere i tag <parameter> e in base al suo attributo 'type' cerca nei suoi ParameterParser registrati quello che supporta il valore dell'attributo, per poi delegare ad esso il parsing del tag stesso. Per essere più chiaro:

// pseudocodice che presuppone la lettura in 'pull' dei tag XML:
Map<String, ParameterParser> registeredParsers = ...;
List<Parameter> paramList = new ArrayList<Parameter>();
for (String tag : tags) {
  if ("parameter".equals(tag.getName())) {
    String tagType = tag.getAttribute("type");
    paramList.add(registeredParsers.get(tagType).parse(tag));
  }
}

In realtà questo è ancora possibile senza introdurre per forza l'interfaccia Parameter ma, se non hai problemi di performances/risorse, la sua presenza permette di rendere più leggibile il codice e di eventualmente delegargli alcune funzionalità, come la registrazione del rispettivo ParameterParser o eventuali controlli di validità del contenuto del parametro stesso.

La lista è consigliabile perchè più rassomigliante alla fonte dati (stream XML) finchè non ci sono validi motivi per preferirgli la mappa, visto che per gli ordinamenti esistono i metodi sort() della classe Collections che puoi utilizzare in ogni momento.

Spero di esserti stato utile.

[andbin]

Originariamente inviato da Angus

Scusa se rispondo solo adesso. Per come hai esposto il problema direi che non ci sono elementi sufficienti per affermare che il design non è buono...

È già un buon inizio ... almeno per me!

Originariamente inviato da Angus

Non conoscendo l'utilizzo e l'utilizzatore di questi 'parametri'

Lo spiego subito. L'applicazione "C" è un software gestionale a interfaccia "carattere" e naturalmente fa utilizzo di basi di dati ma non ha capacità "grafiche".
La necessità era quello di poter creare dei grafici (diagrammi a barre, a torta, ecc...) e l'idea che mi era venuta è quella di usare Java insieme alla libreria JFreeChart (non so se la conosci). Questa libreria ho già avuto modo di provarla e la trovo molto utile e valida.
In sostanza è per questo motivo che devo creare un piccolo strato software in Java che si occupa di prelevare tutti i dati generati dall'applicazione "C" per poi renderli disponibili ad altre classi (che svilupperò io oppure anche altre persone) che si occuperanno di creare a video i grafici.

Il codice che mi hai postato non mi è chiaro al 100%, comunque ho capito il concetto che volevi esprimere: creare un sistema a plugin in cui una certa classe conosce, a run-time, tutte le classi relative ai parametri e in base al nome del tag XML, richiama la classe corrispondente per delegargli l'elaborazione dei tag. Giusto?
Comunque mi sembra un po' complesso per quello che volevo fare io.

A me invece è venuta in mente la seguente cosa.
Creare una classe astratta GenericParameter che contiene tutti i metodi get/set possibili (es. getString, getInt, getDoubleArray1D, setDouble, ecc...). Ognuno di questi metodi, nella classe astratta, ha come unica implementazione il lancio di una eccezione (es. IllegalOperationException che creo io).
Da questa classe astratta derivo N classi es. StringParameter, DoubleArray1DParameter, ecc...
In queste sottoclassi gestisco solo i metodi che sono "il linea" con il tipo di dato gestito.
A questo punto posso avere un TreeMap<String,GenericParameter>. Nota che preferirei usare una Map invece di una lista. Ad ogni parametro è associato un nome, quindi è una gestione "associativa". Le classi che si occuperanno di creare i grafici, estrarranno i dati "per nome".

Una cosa che si potrebbe obiettare a questo metodo è che per creare un nuovo tipo di dato (sottoclasse), bisogna modificare anche la classe base astratta. È un cattivo design?? Cosa ne pensi??

Originariamente inviato da Angus

Spero di esserti stato utile.

Certamente! Grazie.

[Angus]

Originariamente inviato da andbin

È già un buon inizio ... almeno per me!

Lo spiego subito. L'applicazione "C" è un software gestionale a interfaccia "carattere" e naturalmente fa utilizzo di basi di dati ma non ha capacità "grafiche".
La necessità era quello di poter creare dei grafici (diagrammi a barre, a torta, ecc...) e l'idea che mi era venuta è quella di usare Java insieme alla libreria JFreeChart (non so se la conosci). Questa libreria ho già avuto modo di provarla e la trovo molto utile e valida.
In sostanza è per questo motivo che devo creare un piccolo strato software in Java che si occupa di prelevare tutti i dati generati dall'applicazione "C" per poi renderli disponibili ad altre classi (che svilupperò io oppure anche altre persone) che si occuperanno di creare a video i grafici.

Il codice che mi hai postato non mi è chiaro al 100%, comunque ho capito il concetto che volevi esprimere: creare un sistema a plugin in cui una certa classe conosce, a run-time, tutte le classi relative ai parametri e in base al nome del tag XML, richiama la classe corrispondente per delegargli l'elaborazione dei tag. Giusto?

Giusto ;-)

Comunque mi sembra un po' complesso per quello che volevo fare io.

A me invece è venuta in mente la seguente cosa.
Creare una classe astratta GenericParameter che contiene tutti i metodi get/set possibili (es. getString, getInt, getDoubleArray1D, setDouble, ecc...). Ognuno di questi metodi, nella classe astratta, ha come unica implementazione il lancio di una eccezione (es. IllegalOperationException che creo io).
Da questa classe astratta derivo N classi es. StringParameter, DoubleArray1DParameter, ecc...
In queste sottoclassi gestisco solo i metodi che sono "il linea" con il tipo di dato gestito.
A questo punto posso avere un TreeMap<String,GenericParameter>. Nota che preferirei usare una Map invece di una lista. Ad ogni parametro è associato un nome, quindi è una gestione "associativa". Le classi che si occuperanno di creare i grafici, estrarranno i dati "per nome".

E' un ottimo motivo per preferire una mappa ad una lista.

Una cosa che si potrebbe obiettare a questo metodo è che per creare un nuovo tipo di dato (sottoclasse), bisogna modificare anche la classe base astratta. È un cattivo design?? Cosa ne pensi??

E' un cattivo design proprio per le obiezioni che ti sei posto da solo. GenericParameter dovrà essere utilizzata da qualcuno: ti consiglio di immedesimarti per un attimo nell'utilizzatore di tale mappa e degli oggetti contenuti. Prova a scrivere una bozza di codice per creare i tuoi grafici facendo finta che tutta l'infrastruttura precedente sia stata già progettata. Forse così ti verrà un'idea migliore sui metodi che dovrà possedere la classe GenericParameter, o se in realtà magari anche a questo livello ti risulta più semplice usare il concetto di 'delega' del comportamento. L'importante è non perdere mai d'occhio l'utilizzo effettivo delle tue api che intendi 'imporre'.