2025-10-27
MeetingTime APIObjective: To practice applying key API design principles (clarity, usability, preventing misuse) by designing a simple, robust API.
Scenario: You are on a team building a new calendar application. Your task is to design the primary class used to represent a time slot for a meeting. The system needs to handle scheduling, detect overlaps, and calculate durations.
In small groups, design a MeetingTime class (or struct/interface). Don’t write the implementation; focus only on the public-facing API: class name, constructor(s), public methods, and properties.
A senior developer has provided a first-pass “bad” API to get you started. Critique this API first, then design a better one.
// Represents a time slot for a meeting
public class MeetingTime {
// Constructor uses 24-hour time, e.g., 13, 30 -> 1:30 PM
public MeetingTime(int startHour, int startMinute, int endHour, int endMinute);
// Returns the duration of the meeting
public int getDuration();
// Is this meeting at the same time as another?
public boolean conflicts(MeetingTime other);
}Discuss with your group and identify at least three specific flaws with the MeetingTime API above, based on Joshua Bloch’s principles. Think about:
Design a new, improved API for representing a meeting time. As you design, consider the following questions inspired by Bloch’s lecture:
MeetingTime? (e.g., a meeting that ends before it starts, or has an hour of 25).conflicts the best choice? What about overlapsWith? Is there a difference?Share your new API design with the class and justify your decisions using the principles from the lecture.

Neil Ernst ©️ 2024-5