Suggestion: A Proposal to Refactor CourseRoster Class to Improve Adherence to SOLID Principles

[Mad1232]

Proposal to Refactor CourseRoster Class to Improve Adherence to SOLID Principles

Class: Software Architecture & Design(Iowa State University)
Team: Prakarsha Poudel, Caleb Zea, Justin Stevens, Anthony Lopez, Jaden Burke
Instructor: Mouly Kumar
Date: Mar 1, 2025

---

Subject: Proposal to Refactor CourseRoster Class to Improve Adherence to SOLID Principles

Dear TEAMMATES Development Team,

We are writing to formally propose a refactor to the CourseRoster class located in:
teammates/src/main/java/teammates/common/datatransfer/CourseRoster.java

This proposal is based on a detailed analysis conducted by our team, where we reviewed TEAMMATES' adherence to modular architecture principles and the SOLID design principles.

---

Background

The CourseRoster class currently handles several distinct responsibilities:

• Managing the overall course roster.
• Acting as a data transfer object (DTO) for individual participants within the roster.
• Providing helper methods for retrieving participant information.
• Defining a nested static class, ParticipantInfo, which encapsulates participant data such as names and email addresses.

This design results in a violation of the Single Responsibility Principle (SRP) by combining roster management logic with participant data representation within a single class. This coupling reduces the clarity, maintainability, and flexibility of the codebase.

---

Proposed Refactor

We propose extracting the ParticipantInfo class from CourseRoster into a dedicated file, ParticipantInfo.java, which would reside in the same package.

This simple change would:

• Improve modularity by isolating participant data handling into its own class.
• Simplify CourseRoster, ensuring it focuses solely on roster-related functionality.
• Make ParticipantInfo reusable across other parts of the system if similar data structures are needed in the future.

---

Example

Current: Inside CourseRoster.java

public static final class ParticipantInfo {
    private String name;
    private String email;
    // Other fields and methods
}

---

Proposed: New file ParticipantInfo.java

public class ParticipantInfo {
    private String name;
    private String email;
    // Other fields and methods
}

Benefits

• Improved adherence to the Single Responsibility Principle (SRP).
• Enhanced readability and separation of concerns.
• Increased flexibility if participant data structures need to be extended or reused elsewhere in the system.
• Simplified maintenance, as changes to participant-related logic are isolated from roster management logic.

---

Expected Impact

This proposed change would have a minimal impact on existing code and functionality. Existing test cases that reference CourseRoster.ParticipantInfo would need minor updates to refer to the standalone ParticipantInfo class. No changes are expected to external APIs or user-facing features.

---

Request for Feedback

We welcome feedback from the maintainers on:

• Whether this refactor aligns with TEAMMATES’ architectural guidelines and best practices.
• Whether there are any specific conventions regarding data transfer objects (DTOs) that we should follow.
• Any additional recommendations to further improve the structure of CourseRoster.

Our team is committed to ensuring that all communication with the TEAMMATES community is respectful and constructive. All external communication will be handled by our designated project liaison to streamline collaboration.

We greatly appreciate your time and consideration and look forward to your feedback.