Design a Dormitory Room-Assignment System (OOD)

You are asked to design the object-oriented model for a **dormitory room-assignment system**. You are given a set of students and a set of rooms. Each room has a fixed **capacity type** — either a **two-person room** or a **four-person room** — and a corresponding number of beds. Each student submits a single **room-size preference** (they want either a two-person room or a four-person room). Your job is to design a system that assigns students to rooms in a way that respects their preferences and never over-fills a room. Focus on the **class design, the data structures, and the assignment logic** — the algorithm itself is intentionally simple. Walk through: - the classes you would introduce and the responsibilities of each, - how you would store students, rooms, and the in-progress assignment, - the method(s) that drive the assignment, - how you handle the case where a preference cannot be satisfied (e.g. more students want four-person rooms than there are beds in four-person rooms). ```hint Where to start This is an OOD prompt, not a clever-algorithm prompt. Begin by naming the three nouns in the problem — `Student`, `Room`, and the coordinator/service that owns the assignment — and give each a single clear responsibility before you write any allocation code. ``` ```hint Modeling the room types Two-person and four-person rooms differ only by capacity. Model that with a `RoomType` enum (or a `capacity` field) rather than two separate subclasses, so adding a "six-person room" later is a one-line change and the assignment logic stays generic. ``` ```hint Assignment data structure Group available rooms by their capacity type — e.g. `Map<RoomType, Queue<Room>>` — so that satisfying a student's preference is "pop the next room of the requested type that still has a free bed." Track each room's remaining beds so a four-person room can take up to four students before it leaves the pool. ``` ### Constraints & Assumptions - Each student has exactly one room-size preference: two-person or four-person. - Each room has a fixed capacity (2 or 4 beds) and may hold multiple students up to that capacity. - A student is assigned to at most one room. - The input sizes are small enough to fit in memory (hundreds to low thousands of students/rooms); no database or distributed coordination is required. - The assignment runs as a one-shot batch (not an online stream), but the design should make it easy to re-run or extend. - Total capacity is not guaranteed to match demand, so some students may be left unassigned — the system must report this rather than crash or silently overflow a room. ### Clarifying Questions to Ask - Is a student's preference a **hard requirement** (must get that room type or stay unassigned) or a **soft preference** (fall back to the other type if their preferred type is full)? - Can a room be partially filled — e.g. a four-person room holding only three students — or must rooms be filled to capacity? - Are there any grouping constraints (roommates who must be placed together, gender-segregated floors, etc.), or is every student independent? - What should happen to students who cannot be placed — return them in an "unassigned" list, throw, or assign them to any leftover bed? - Is the assignment a single batch run, or do students and rooms arrive incrementally and need re-assignment over time? - Are room IDs and student IDs guaranteed unique, and can the same student appear twice in the input? ### What a Strong Answer Covers ```premium-lock What a Strong Answer Covers ``` ### Follow-up Questions - How would your design change if a student could submit a **ranked list** of preferences (first choice four-person, second choice two-person) instead of a single one? - Suppose students arrive **one at a time over a registration period** rather than all at once. How would you adapt the classes and data structures to support incremental, online assignment? - Add a constraint that **groups of friends must be placed in the same room when possible**. How does this change the model and the assignment algorithm, and what new conflicts can arise? - How would you make the assignment **deterministic and testable** — i.e. the same input always produces the same output — and what unit tests would you write to prove capacity is never exceeded?