Meal Builder: Changes & Effects

1️⃣ Added Diet Versions of Beverages

What I did: I added two new classes:

• DietCoke
• DietPepsi

Why: This allows customers to choose a diet version of Coke or Pepsi.

Effect: Now, when the user selects a diet option, the system can include the diet drink in their meal without changing the existing MealBuilder or Meal classes.

---

2️⃣ Added a New Hot Drink: Tea

What I did: I introduced:

• HotDrink (abstract class)
• Tea (concrete class)
• Cup (implements Packing)

Why: To add a new hot drink option, modeled similarly to how cold drinks work.

Effect: This allows Tea to be treated as a standard Item and added easily to any meal, with packaging type Cup.

---

3️⃣ Made Tea Decoratable (Sweetness & Cream)

What I did: Implemented the Decorator Pattern with:

• TeaDecorator (abstract decorator)
• SweetnessDecorator
• CreamDecorator

Why: To allow dynamic customization of Tea (add sugar, honey, cream).

Effect: This makes Tea flexible; customers can add custom sweetness or cream, and the system updates both the name and price automatically (e.g., "Tea + 2 spoons of Sugar + Cream").

---

4️⃣ Made the Demo Interactive

What I did: Modified the BuilderPatternDemo to:

• Prompt the user for Veg/Non-Veg meal selection
• Ask if they want a Diet drink
• Offer Tea, and let them customize it (sweetness type, spoons, cream)

Why: To move from a static demo to an interactive experience, making it feel like a real ordering system.

Effect: Users can now build their meal step-by-step with personalized choices. Only the BuilderPatternDemo was changed to achieve this; no need to touch other core classes.

---

✅ Overall Benefits

• Extensibility: New drinks (like Tea) and decorators (like sweetness) are easy to add in the future.
• Reusability: The Decorator pattern lets us reuse the same Tea base class with different combinations of add-ons.
• Single Responsibility: Each class has a clear purpose, keeping the design clean and maintainable.