Il problema è: come rappresentiamo l' id che sarà condiviso da tutti i DTO?

Tutti gli oggetti della gerarchia ereditano i metodi di accesso (setter e getter) all'id dalla classe BaseDto,  inoltre va considerato che ogni oggetto potrebbe avere per l' id un qualsiasi tipo java.
La soluzione che abbiamo adottato è stata quella di definire l’ id come Object. (Non è l'unica soluzione e neppure la migliore, ma si presta bene per evidenziare  i vantaggi dell'uso dei generics.)

Nel package org.generics.esempio1   (che torvate in allegato in questo articolo), vediamo come implementare il codice della gerarchia e come usarlo senza sfruttare i generics.

Attenzione: abbiamo messo in evidenza le righe di codice critiche (cioè quelle che più saranno coinvolte dalla riscrittura dello stesso esempio con i generics).

Il codice della classe BaseDto :

package org.generics.esempio1.dto;

public class BaseDto {
private Object id;
public Object getId() {
return id;
}
public void setId(Object id) {
this.id = id;
}
public boolean equals(Object object) {
if (object != null) {
if (object instanceof BaseDto) {
BaseDto dto = (BaseDto) object;
if (dto.getId() != null && getId() != null) {
return dto.getId().equals(getId());
}
}
}
return false;
}
}

Il codice della classe OrdineDto :

package org.generics.esempio1.dto;

import java.util.List;

public class OrdineDto extends BaseDto {
    private List prodotti;
    public List getProdotti() {
        return prodotti;
    }
    public void addProdotti(List prodotti) {
            if(this.prodotti==null)this.prodotti = new ArrayList();
        this.prodotti.addAll(prodotti);
    }
    public Double getTotale(){
        Double totale = .00;
        for (Object prodotto : prodotti) {
            totale += ((ProdottoDto) prodotto).getPrezzo();
        }
        return totale;
    }
    public boolean addProdotto(ProdottoDto prodotto){
        if(prodotti==null)prodotti = new ArrayList();
        return prodotti.add(prodotto);
    }

    public boolean removeProdotto(ProdottoDto prodotto){
        if(prodotti!=null){
            return prodotti.remove(prodotto);
        }
        return true;
    }
}

 

 Il codice delle altre classi  DTO non viene riportato per esteso nell’articolo, ma si può trovare nel file src.zip, in allegato.

Consideriamo anche come un client potrebbe utilizzare queste classi per creare e stampare un ordine (org.generics.esempio1.test.TestaCodice.java) .

Questo il codice per creare un libro:

List prodotti = new ArrayList();
LibroDto libroTmp;
String autoreTmp;
libroTmp = new LibroDto();
autoreTmp = "Stephen King";
libroTmp.setId(1);
libroTmp.setAutore(autoreTmp);
libroTmp.setNumeroPagine(202);
libroTmp.setPrezzo(22.30);
libroTmp.setTitolo("IT");
prodotti.add(libroTmp);

Questo approccio implica alcuni svantaggi che, vengo in parte risolti dai generics.

Gli svantaggi sono:

1.Ogni volta che vogliamo accedere al valore dell'id di un DTO, dobbiamo controllare che il tipo sia corretto e castarlo per poter accedere ai metodi dello stesso. Si pensi per esempio al tipo Date (secondo me sconsigliabile come campo chiave), in fase di presentazione richiede di essere formattato.

2.Il compilatore non sa se il tipo di dato passato al metodo setId(Object id) sia corretto.

3.Dal punto 2 segue anche che, il codice presentato, si presta ad un errore runtime di cast exception. Per esempio nel caso in cui l' id venga valorizzato da un client con un tipo di dato sbagliato, tuttavia accettato dal metodo setId(Object id).

4.Un altro possibile problema si presenta in fase di refactoring. 
Si immagini per esempio di cambiare il tipo dell'id dei libri da int a String per adottare l' isbn(cioè un codice alfanumerico) come chiave.
Stando al codice, ci dovremmo limitare a passare il codice isbn al metodo setId(Object id) in formato String, dato che è un codice alfanumerico.
Sopraggiunge però un problema perché il compilatore non rileva tutti i cast a Integer presenti nel codice, si è costretti a cercare tutte le chiamate al metodo getId() e sostituire l'eventuale cast al vecchio tipo con il nuovo.