Dubbio progettazione classe

[tmh21]

Salve,
Ho un dubbio forse banale su come progettare una classe... il minimo indispensabile da sapere è che ho una classe Interventi che rappresenta degli interventi assistenziali svolti.
Stando ai requisiti funzionali, un intervento può avere diversi tipi di Anomalie, ne cito tre che sono emblematici:
[list=1][*]Ritardo: l'intervento è iniziato con più di n minuti di ritardo.[*]Allontanamento: chi ha effettuato l'intervento si è allontanato di oltre n metri dal luogo dell'intervento.[*]Inattività: chi ha effettuato l'intervento è restato inattivo per più di n minuti.[/list=1]
Non è importante capire a fondo la semantica di questi requisiti, ciò che mi interessa adesso è come strutturare la classe Intervento in merito alle Anomalie, sapendo che il DB è già stato progettato in questo modo:

• Interventi(id, altri_campi)
• Ritardi(id_intervento)
• Allontanamenti(id_intervento, distanza, ora_inizio, ora_fine)
• Inattivita(id_intervento, ora_inizio, ora_fine)

Per i ritardi sarebbe bastato anche mettere un campo booleano nella tabella interventi (tanto la corrispondenza è di tipo 1 a 1), ma tanto anche fatto in questo modo poco cambia.

Ora, il mio problema è il seguente:
Avevo pensato di mettere all'interno della classe interventi un attributo del genere

ArrayList<Anomalia> anomalie;

ma il problema è come progettare la classe Anomalia?

Il problema è che a seconda del tipo di anomalia, gli attributi della stessa variano... potrei fare diverse classi che estendono la classe Anomalia, ma poi come potrei capire di che tipo di anomalia si tratta iterando sull'ArrayList anomalie e quindi ad accedere ai relativi attributi?

Mettere diversi attributi per i diversi tipi di anomalia mi sembra brutto... alla fine sono tutte anomalie, anche se di diverso tipo e con diversi attributi.... ma non saprei proprio come fare.

[Brazonet]

Originariamente inviato da tmh21
Salve,
Ho un dubbio forse banale su come progettare una classe... il minimo indispensabile da sapere è che ho una classe Interventi che rappresenta degli interventi assistenziali svolti.
Stando ai requisiti funzionali, un intervento può avere diversi tipi di Anomalie, ne cito tre che sono emblematici:
[list=1][*]Ritardo: l'intervento è iniziato con più di n minuti di ritardo.[*]Allontanamento: chi ha effettuato l'intervento si è allontanato di oltre n metri dal luogo dell'intervento.[*]Inattività: chi ha effettuato l'intervento è restato inattivo per più di n minuti.[/list=1]
Non è importante capire a fondo la semantica di questi requisiti, ciò che mi interessa adesso è come strutturare la classe Intervento in merito alle Anomalie, sapendo che il DB è già stato progettato in questo modo:

• Interventi(id, altri_campi)
• Ritardi(id_intervento)
• Allontanamenti(id_intervento, distanza, ora_inizio, ora_fine)
• Inattivita(id_intervento, ora_inizio, ora_fine)

Per i ritardi sarebbe bastato anche mettere un campo booleano nella tabella interventi (tanto la corrispondenza è di tipo 1 a 1), ma tanto anche fatto in questo modo poco cambia.

Ora, il mio problema è il seguente:
Avevo pensato di mettere all'interno della classe interventi un attributo del genere

ArrayList<Anomalia> anomalie;

ma il problema è come progettare la classe Anomalia?

Il problema è che a seconda del tipo di anomalia, gli attributi della stessa variano... potrei fare diverse classi che estendono la classe Anomalia, ma poi come potrei capire di che tipo di anomalia si tratta iterando sull'ArrayList anomalie e quindi ad accedere ai relativi attributi?

Mettere diversi attributi per i diversi tipi di anomalia mi sembra brutto... alla fine sono tutte anomalie, anche se di diverso tipo e con diversi attributi.... ma non saprei proprio come fare.

Se hanno almeno un attributo in comune (per esempio l'id univoco) è corretto creare una superclasse anomalia e per capire di che tipo si tratta puoi usare il predicato "instanceof".

if (classeAnomalia instanceof Intervento)
   ...

Se non ci sono elementi in comune e vuoi comunque creare qualcosa che accomuni, puoi pensare a un'interfaccia o a una classe astratta dove dichiarare metodi che possono presentarsi in tutti e tre i casi (per esempio getAnomalia() che nell'implementazione restituisce i dati persistenti).

L'ultima soluzione, nel caso non ci sono elementi in comune, potrebbe essere quella di utilizzare la reflection.

[valia]

la soluzione migliore (almeno per me) è scrivere bene una gerarchia di classi: sei davanti una Anomalia, bene questa è la tua classe base.

Le varie sotto-anomalie che derivi devono ereditare da questa.
Come ti comporti con i vari attributi?
Te ne freghi, devi fissare

1. attributi comuni nella superclasse
2. metodi comuni nella superclasse.

devi decidere cosa ci puoi fare con una anomalia, runtime del valore dei campi (che alcuni hanno e alcuni no) non ti interessa, sai che puoi fare delle azioni sull'anomalia e la risposta la puoi dedurre in base a questi campi.

IN questo modo tu parli sempre di anomalie e di azioni sulle stesse, senza guardare al contenuto

Il fatto che devi usare instanceof per decidere cosa fare è sintomo che ti stai perdendo qualcosa. quella è una parola chiave che meno uso meglio è (ovviamente in alcuni casi non puoi farne a meno).
Inoltre, aggiungere una anomalia, con instanceof diventa un bagno di sangue, usando la OOP alla fine diventa chiamare correttamente il metodo che crea l'istanza (dopo aver provveduto a determinare il comportamento della nuova Anomalia)

[tmh21]

Originariamente inviato da Brazonet
[...]

Reflection ed instanceof sono due cose che vorrei evitare, non mi sembra il caso. Credo che esista un modo per fare tutto in una maniera più elegante, altrimenti per fare un esempio tanto vale usare anche i goto nella programmazione procedurale

L'interfaccia non è adatta, dato che non devo descriverne i comportamenti bensì solo la struttura (alla fine sono semplici classi POJO con nulla più di getters e setters, tutte le manipolazioni sui loro dati avvengono a livelli superiori).

La classe astratta invece mi sembra l'idea giusta, il problema è che un metodo come getAnomalia() anche se come idea non è male, in pratica non si può attuare: cosa dovrebbe restituire? Una List<Object> con tutti i parametri? E la conoscenza di quanti e quali parametri a chi spetta, agli utilizzatori di tale metodo? Non ci siamo...

Originariamente inviato da valia
la soluzione migliore (almeno per me) è scrivere bene una gerarchia di classi: sei davanti una Anomalia, bene questa è la tua classe base.

Sono d'accordo... potrei fare qualcosa tipo:

public abstract class Anomalia {
}

public abstract class AnomaliaTempo {
    private Date oraInizio;
    private Date oraFine;

    //getters & setters
}

public class Ritardo extends Anomalia {
    private Date tempo;

    //getters & setters
}

public class Allontanamento extends AnomaliaTempo {
    private int distanza;

    //getters & setters
}

public class Inattivita extends AnomaliaTempo {
}

Ora, ciò che non mi convince è che ho altri tipi di anomalia che hanno come soli dati oraInizio e oraFine... non posso mica fare altre classi che alla fin fine sarebbero solo dei "cloni", tipo:

public class AltraAnomalia1 extends AnomaliaTempo {
}

public class AltraAnomalia2 extends AnomaliaTempo {
}

E resta il fatto che non saprei come utilizzarle nella classe Intervento, se creando tanti attributi quante sono le classi concrete.




EDIT:
Un'alternativa sarebbe questa:

public class Intervento {
    private int id;
    //altri campi
    private boolean ritardo;
    private int distanza;
    private List<Anomalia> anomalie;

    //getters & setters
}

public class Anomalia {
    public static final int ALLONTANAMENTO = 1;
    public static final int INATTIVITA = 2;
    public static final int ALTRA_ANOMALIA1 = 3;
    public static final int ALTRA_ANOMALIA2 = 4;

    private int tipo;
    private Date oraInizio;
    private Date oraFine;

    //getters & setters
}

In questo modo sarebbe possibile iterare sulle anomalie dell'intervento e capirne il tipo... la cosa che non mi convince però è l'attributo distanza all'interno della classe Intervento, che oltre ad essere semanticamente poco collegato con la classe, sarebbe anche inutile quando l'istanza di intervento non ha alcuna anomalia di tipo Anomalia.ALLONTANAMENTO.

[valia]

getAnomalia restituisce

List<Anomalia>

dove Anomalia è la classe base.

Ripeto, vedi bene l'organizzazione, non mi sembra il massimo così fatta

[tmh21]

valia, ho editato la mia risposta precedente... sinceramente non so bene come potrei fare...

[valia]

Originariamente inviato da tmh21
In questo modo sarebbe possibile iterare sulle anomalie dell'intervento e capirne il tipo... la cosa che non mi convince però è l'attributo distanza all'interno della classe Intervento, che oltre ad essere semanticamente poco collegato con la classe, sarebbe anche inutile quando l'istanza di intervento non ha alcuna anomalia di tipo Anomalia.ALLONTANAMENTO.

questo è già più corretto dal punto di vista OOP, in quanto è il polimorfismo ad occuparsi di alcuni dettagli implementativi che tu dovevi risolvere con instanceof o reflection.
Riguardo al quel tuo particolare problema: avrai un valore di default, quando l'istanza è di tipo ALLONTANAMENTO, il metodo getDistanza ritorna cmq -1, valore che indica distanza invalida.
Negli altri casi distanza a -1 è sintomo di qualcosa che non va.


ps il tipo lo definirei tramite enum (quindi una classe che fa da enum) , è più ordinato

[tmh21]

Originariamente inviato da valia
[...]
ps il tipo lo definirei tramite enum (quindi una classe che fa da enum) , è più ordinato

Sì, effettivamente l'uso di enum è una pratica indubbiamente migliore, ma il fatto che anche le librerie standard di java non lo usino non mi stimola ad usarlo (anche perché è fastidioso definire nuove classi enum per ogni cavolata, tipo anche il sesso etc).


Cmq ci ho pensato un po' su e credo che farò così:
dato che la classe intervento è una classe entity la cui unica funzione è rappresentare strutturalmente un intervento, anche al fine di avere una più semplice corrispondenza con l'organizzazione del DB, metterò diversi attributi per diverse anomalie, tipo:

public class Intervento {
    private int id;
    //altri campi
    private boolean ritardo;
    private ArrayList<Allontanamento> allontanamenti;
    private ArrayList<Inattivita> inattivita;
    private ArrayList<AltraAnomalia1> altreAnomalie1;
    private ArrayList<AltraAnomalia2> altreAnomalie2;

    //oppure forse è meglio
    private ArrayList<AnomaliaTempo> inattivita;
    private ArrayList<AnomaliaTempo> altreAnomalie1;
    private ArrayList<AnomaliaTempo> altreAnomalie2;
    //ovviamente rendendo la classe AnomaliaTempo concreta.
}

Forse è un po' brutto, ma mi sembra che rispecchi di più lo schema del DB e le relazioni tra i vari tipi di anomalie rispetto ad uno specifico intervento.
(In particolare un intervento può avere:
- 0..1 ritardo;
- 0..N allontanamenti
- 0..N inattivita
- 0..N altraAnomalia1
- 0..N altraAnomalia2)

Pareri?

[valia]

Originariamente inviato da tmh21

Pareri?

la scelta è tua, a mio parere non stai usando l'OOP.
L'enum non te lo ritrovi tra le librerie standard perché tante sono state scritte molto tempo prima che il costrutto venisse introdotto nel linguaggio (se non ricordo male è una nuova feature della 1.5), quindi, per motivi di legacy, quello che già esiste resta senza enum.
Trovo più ordinato avere una enum (senza esagerare per il sesso) e una sola collection come ti dicevo, è più semplice la gestione del codice.
Non pensare di dover per forza essere legato (corrispondenza biunivoca col db) perché in questo caso il db è antecedente la tua app e quindi, a meno di cambiamenti, non puoi fare molto.
Poi visto che la corrispondenza biunivoca non puoi averla, meglio avere un wrapper che maschera un po' il db, ci guadagni in manutenibilità e possibiltà di estensione

[tmh21]

Originariamente inviato da valia
la scelta è tua, a mio parere non stai usando l'OOP.
L'enum non te lo ritrovi tra le librerie standard perché tante sono state scritte molto tempo prima che il costrutto venisse introdotto nel linguaggio (se non ricordo male è una nuova feature della 1.5), quindi, per motivi di legacy, quello che già esiste resta senza enum.
Trovo più ordinato avere una enum (senza esagerare per il sesso) e una sola collection come ti dicevo, è più semplice la gestione del codice.
Non pensare di dover per forza essere legato (corrispondenza biunivoca col db) perché in questo caso il db è antecedente la tua app e quindi, a meno di cambiamenti, non puoi fare molto.
Poi visto che la corrispondenza biunivoca non puoi averla, meglio avere un wrapper che maschera un po' il db, ci guadagni in manutenibilità e possibiltà di estensione

Mmmm.. ok grazie.

Allora mi sa che non mi conviene fare come ho detto poco fa.

Ma non basta il DAO a mascherare il DB? Posso incapsulare lì tutta la logica di accesso al database...