Un setter con l'oggetto composto come parametro migliore o setter separato per ogni parametro all'interno dell'oggetto composto?

Question

Un setter con l'oggetto composto come parametro migliore o setter separato per ogni parametro all'interno dell'oggetto composto?

#1 da (2 voti)
#2 da (2 voti)
#3 da (1 voti)

2

Ho due idee su come procedere con una classe di disponibilità, ma non sono sicuro di quale sia la migliore.

public class TimeRange {
private Timestamp startTime;
private Timestamp endTime;

public TimeRange() {
    //set defaults
}
// appropriate getters
//setters
public void setStartTime(Timestamp startTime) {
    this.startTime = startTime;
}

public void setEndTime(Timestamp endTime) {
    this.endTime = endTime;
}
// some code that validates the object is in a valid state.
}

Prima idea:

public class WeeklyAvailabilities {
private TimeRange mondaySlot;
private TimeRange tuesdaySlot;
private TimeRange wednesdaySlot;
private TimeRange thursdaySlot;
private TimeRange fridaySlot;
private TimeRange saturdaySlot;
private TimeRange sundaySlot;

public WeeklyAvailabilities() {
   // set defaults
}
// some getters and such
public void setMondayStartTime(Timestamp start) {
   mondaySlot.setStartTime(start);
}

public void setMondayEndTime(Timestamp end) {
   mondaySlot.setEndTime(end);
}
// continue the pattern for all the slots
}

Seconda idea:

public class WeeklyAvailabilities {
private TimeRange mondaySlot;
private TimeRange tuesdaySlot;
private TimeRange wednesdaySlot;
private TimeRange thursdaySlot;
private TimeRange fridaySlot;
private TimeRange saturdaySlot;
private TimeRange sundaySlot;

public WeeklyAvailabilities() {
   // set defaults
}
// some getters and such
public void setMondaySlot(TimeRange mondaySlot) {
   this.mondaySlot = mondaySlot;
}

// continue the pattern for all the slots
}

Sono in conflitto a causa del fatto che la prima idea non richiede la creazione di un nuovo oggetto ogni volta che la seconda idea richiede qualcosa del genere. Mi chiedo davvero se potrei avere qualche input su quale sia migliore o se ci potrebbe essere una terza opzione che sto trascurando completamente.

design java

posta Sahil Tara 07.12.2018 - 18:53

fonte

3 risposte

2

Senza ulteriori informazioni, la tua seconda idea sembra migliore, perché semplifica le interazioni con TimeRange (riduzione dell'accoppiamento), e ti consente di delegare a quella classe i controlli di coerenza.

Considerare anche questo refactoring, che riduce la replica del codice e migliora la manutenibilità:

import java.util.*;

public class WeeklyAvailabilities {
    public static enum WeekDay { MONDAY, TUESDAY, ... };

    private Map<WeekDay,Integer> slots = new EnumMap<>(WeekDay.class);

    public WeeklyAvailabilities() {
    // set defaults
    }

    // some getters and such
    public void setSlot(WeekDay day, Integer slot) {
        slots.put(day, slot);
    }

// continue the pattern for all the slots
}

risposta data 09.12.2018 - 12:50

fonte

1

La tua prima opzione sconfigge lo scopo della classe TimeRange, potresti anche avere direttamente 14 TimeStamp in WeeklyAvailabilities. Quale non sarebbe necessariamente così male se si desidera consentire la popolazione incrementale di WeeklyAvailabilities ma si perderebbe il concetto di time slot, ottenendo un modello più piatto.

Per evitare il disordine e una quantità inutile di metodi, userei un enumer di WeekDay come secondo argomento in setSlot. E cambia il nome da TimeRange a TimeSlot perché ora usi due parole diverse per la stessa cosa.

risposta data 08.12.2018 - 20:09

fonte

Leggi altre domande sui tag design java

Riconciliazione MVC con un modello di strategia Pessima idea mostrare le informazioni del server di posta nel progetto github pubblico?

score 2 · Accepted Answer

Entrambe le idee hanno i loro pro e contro in molti aspetti diversi, con la quantità di creazione dell'istanza che è una delle meno importanti.

La cosa più importante è: quali sono le variazioni di stato di WeeklyAvailabilities che vuoi supportare, assicurandoti che qualunque setter qualcuno chiami in qualsiasi situazione, si ottiene sempre uno stato consistente (o genera un'eccezione). E prevedi davvero eventuali modifiche a un'istanza WeeklyAvailabilities dopo l'inizializzazione?

Quindi le domande sono:

In che modo un'istanza WeeklyAvailabilities raggiunge il suo stato iniziale? Sembra esserci un'impostazione predefinita nel costruttore no-args. Ogni istanza di WeeklyAvailabilities manterrà mai questi valori o verrà tipicamente impostata in singoli time slot, rendendo il costruttore no-args piuttosto inutile, e invece invocherà una full-args (o l'applicazione di alcuni pattern builder).

Pensi che qualcuno vorrà cambiare l'ora di inizio o di fine individualmente, non in coppia? Solo allora dovresti offrire singoli setter.

Per riassumere, la mia ipotesi è che potresti stare meglio con un costruttore diTimeRange al 7% e nessun setter.