Is a setter with the composed object as a parameter better or separate setters for each parameter within the composed object?

Question

I have two ideas on how to proceed with an availability class but I'm not sure which one is better.

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.
}

First 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
}

Second 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
}

I'm conflicted due to the fact that the first idea doesn't require a new object to be created every time while the second idea would require something of the sort. Really just wondering if I could have some input on which one is better, or if there might be a third option that I'm completely overlooking.

Answer 1

Both ideas have their pros and cons in many different aspects, with the amount of instance creation being one of the less important ones.

Most important is: what are the state changes of WeeklyAvailabilities that you want to support, making sure whatever setter someone calls in whatever situation, you always result in a consistent state (or throw an exception). And do you really foresee any changes to a WeeklyAvailabilities instance after its initialization?

Then the questions are:

How does a WeeklyAvailabilities instance reach its initial state? There seems to be a default setting in the no-args constructor. Will any WeeklyAvailabilities instance ever keep these values or will they typically set individual timeslots, making the no-args constructor rather worthless, and instead call for a full-args one (or application of some builder pattern).

Do you think someone will want change the start or end times individually, not pair-wise? Only then should you offer individual setters.

To sum it up, my wild guess is that you might be better off with a seven-TimeRange constructor and no setter at all.

Answer 2

Without further information, your second idea looks better, because it simplifies the interactions with TimeRange (decreasing coupling), and allows you to delegate to that class the consistency checks.

Also consider this refactoring, which reduces code replication and improves maintainability:

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
}

Answer 3

Your first option defeats the purpose of the TimeRange class, you might as well have 14 TimeStamps in WeeklyAvailabilities directly. Which would not necessarily be that bad if you want to allow incremental population of WeeklyAvailabilities but you would lose the time slot concept, getting a flatter model.

To prevent clutter and a needless amount of methods I would use a WeekDay enum as a second argument in setSlot. And change the name TimeRange to TimeSlot because you now use two different words for the same thing.