Devo avere un oggetto come attributo o ID primitivo? [duplicare]

Question

Devo avere un oggetto come attributo o ID primitivo? [duplicare]

#1 da (2 voti)
#2 da (-1 voti)

0

Mi chiedo quale principio dovrei usare. Ecco la mia situazione.

Ho una classe chiamata TravelOffer. Questa classe ha questo aspetto:

public class TravelOffer
{
    private final long id;

    private final StartZone startZone;
    private final EndZone endZone;
    private final List<Waypoint> waypoints;

    private final Period startOff;

    private final User travelCreator;
    private final List<User> participantsList;

    private final TravelExtras travelExtras;

    private final CandidateApprovement candidateApprovement;

    private int numberOfSeats;

    private double pricePerPerson;

    private Luggage luggage;

    private boolean additionalLuggageTransport;

    private String additionalDescription;
}

Come vedi ci sono i seguenti attributi:

User tavelCreator e List<User> participantsList

Quello che mi sto chiedendo è se dovesse essere così o semplicemente sostituire l'oggetto User con String userId e poi da una classe singleton per ottenere l'oggetto User che sarà in una Hashmap?

java design-patterns object-oriented-design

posta Papa-rapa-beo 22.10.2014 - 16:16

fonte

2 risposte

-1

Probabilmente è meglio attenersi a ciò che si ha, cioè come variabile membro di tipo Utente. I singleton di solito sono meglio evitati quando introducono lo stato globale. Al momento la tua classe è un bean senza accessorie o logiche di business, se assumiamo che aggiungerai qualche logica di business a un certo punto, allora vorrai testarlo, avendo l'utente come oggetto (iniettabile) ti permettono di testare meglio la tua classe usando stub o mock. Anche questo tipo di funzionalità tipicamente supportata da un database, ti permetterà di modellare il tuo grafico di classe in un database usando ORM come Hibernate se mantieni l'oggetto membro. Spero che abbia un senso?

risposta data 23.10.2014 - 16:19

fonte

Leggi altre domande sui tag java design-patterns object-oriented-design

Algoritmo per la piastrellatura di una superficie senza tessere adiacenti Accesso efficiente al database per i dati correlati

score 2 · Accepted Answer

Non penso che ci sia una risposta giusta perché entrambe le soluzioni hanno alcuni vantaggi e svantaggi. Uso regolarmente entrambi a seconda della situazione.

Avere l'entità referenziata come oggetto rende questa classe di entità più comoda da usare, ma il lato negativo è che diventa rapidamente complesso gestire tutti questi riferimenti. Una volta che il grafico dell'oggetto diventa più complesso, puoi trovare te stesso in una situazione in cui puoi trovare una catena di riferimenti tra due entità arbitrarie. Pensa cosa succede quando successivamente modifichi la classe User , ad esempio, e aggiungi al membro List<TravelOffer> . Ora hai una dipendenza ciclica e la ricerca di una entità richiede che tu segua il grafico e cerchi un intero gruppo di altre entità che probabilmente non ti serviranno. Tutto questo può essere gestito, ad esempio, con classi proxy e caricamento lento, ma questo ti dà facilmente nuovi problemi di cui preoccuparti.

Avere l'entità referenziata come ID è facile da implementare ma rende la classe di entità meno comoda da usare. Come hai detto tu stesso, ti richiederebbe di effettuare ulteriori ricerche quando utilizzi entità. L'utilizzo di un singleton non sembra una buona idea, quindi questo approccio ti limiterebbe a fare queste ricerche solo in luoghi in cui hai accesso a qualche tipo di repository che sa come risolvere gli ID.