## Design Pattern Selection: Builder Pattern

### Chosen Design Pattern:

For the Campus Event Management System, the **Builder Pattern** has been selected from the provided list. This pattern is a creational design pattern designed to separate the construction of a complex object from its representation. This allows the same construction process to create different representations.

### Justification for Selection:

The primary client requirement that strongly advocates for the Builder Pattern is the need for a "future-proof design" that allows "easy incorporation of new event types, registration schemes, and discount strategies without major redesign." Specifically, the requirement states:

*   "For events with registration fees, the system must calculate: Base registration fee. Additional optional services (e.g., catering or transportation) when selected. Applicable discounts (e.g., early bird discount and group registration discount)."

Creating a `Registration` object can become complex due to the various optional components, such as additional services and different types of discounts. Without a structured approach, the `Registration` class's constructor could become overly complex with a large number of parameters, or require multiple constructors to handle different combinations of optional elements. This leads to what is known as the "telescoping constructor" anti-pattern, which is difficult to maintain and extend.

The Builder Pattern addresses this complexity by providing a step-by-step approach to constructing the `Registration` object. Instead of a single, monolithic constructor, a `RegistrationBuilder` class can be introduced. This builder class would have methods for setting the base registration, adding optional services, and applying various discounts. Each method would return the builder instance itself, allowing for method chaining, which improves readability and usability.

### How the Builder Pattern Enhances Design and Supports Future Expansion:

1.  **Improved Readability and Maintainability:** The Builder Pattern makes the `Registration` object creation process more readable and less error-prone. Instead of passing many parameters to a constructor, each optional component is added via a dedicated method on the builder. This clearly indicates what is being added to the registration.

2.  **Flexibility in Object Construction:** The pattern allows for the creation of `Registration` objects with different combinations of optional services and discounts. New optional services (e.g., accommodation, merchandise) or new discount types (e.g., student discount, loyalty discount) can be easily incorporated by simply adding new methods to the `RegistrationBuilder` interface and its concrete implementations. The core `Registration` class remains unchanged, adhering to the Open/Closed Principle (open for extension, closed for modification).

3.  **Decoupling:** The construction logic is decoupled from the `Registration` object itself. The `Registration` class does not need to know the intricate details of how it is constructed. This separation of concerns makes the system more modular and easier to test.

4.  **Enforcing Invariants:** The Builder can ensure that the `Registration` object is only built when all necessary components are in place, preventing the creation of invalid objects. For example, a `build()` method on the `RegistrationBuilder` could validate that a base fee is set before finalizing the `Registration` object.

### Reflection in the Class Diagram:

To reflect the Builder Pattern, the Class Diagram would be updated to include:

*   **`Registration` Class:** The complex object being built.
*   **`RegistrationBuilder` Interface/Abstract Class:** Defines the interface for creating parts of the `Registration` object.
*   **`ConcreteRegistrationBuilder` Class:** Implements the `RegistrationBuilder` interface, providing concrete implementations for adding services and discounts. This class would hold the intermediate state of the `Registration` object being built.
*   **`Director` (Optional):** A class (e.g., `RegistrationManager`) that uses the `RegistrationBuilder` to construct a `Registration` object. The Director is optional as the client can directly use the builder.

This structure would allow for the addition of new `OptionalService` or `Discount` types without modifying the `Registration` class or the `RegistrationBuilder` interface, only requiring new methods in the `ConcreteRegistrationBuilder` or new concrete builder implementations if the construction process itself varies significantly.


