namespace Ch3Beverage;

public abstract class Beverage {
    public virtual string Description => "Unknown beverage";

    public abstract double Cost();
}

// public static class BeveragePrintExtension {
//     public static void Print(this Beverage value) {
//         Console.WriteLine($"{value.Description} ${value.Cost()}");
//     }
// }
/*
   The only real benefit of putting the constructor in CondimentDecorator is if you need to:
   Add validation logic (e.g., null checks) once for all decorators
   Add shared behavior that all decorators need when wrapping
   Enforce that the wrapped beverage is immutable across all decorators
 *
   If you don't need shared initialization logic, your approach is cleaner and more direct.
   It's a legitimate design choice, not a mistake.
   The "always put it in the base class" advice is dogmatic - useful when you have multiple decorators and want consistency,
   but not a hard rule. Your implementation follows the Decorator pattern correctly.
 */

public abstract class CondimentDecorator(Beverage beverage) : Beverage {
    protected Beverage Beverage { get; } = beverage;
    /*
     * Adding { get; } this Beverage is not a Field but a read-only Property
     * providing a contract that child classes cannot change this value.
     * Leaving a normal field `protected Beverage Beverage = beverage` allows
     * child classes to freely reassign it.
     */
}

public class Espresso : Beverage {
    public override string Description => "Espresso";

    public override double Cost() => 1.99;
}

public class HouseBlend : Beverage {
    public override string Description => "House Blend Coffee";

    public override double Cost() => 0.89;
}

public class DarkRoast : Beverage {
    public override string Description => "Dark Roast Coffee";

    public override double Cost() => 0.99;
}

public class Decaf : Beverage {
    public override string Description => "Decaf Coffee";

    public override double Cost() => 1.05;
}

// Yes, this approach is really uglier because it relies aggressively
// on inheritance (protected "invisible" variable) instead of basic explicit composition.
// But it allows code reuse at the level of the decorator base class...
public class Mocha(Beverage beverage) : CondimentDecorator(beverage) {
    public override string Description => $"{Beverage.Description}, Mocha";

    public override double Cost() => Beverage.Cost() + 0.20;
}

public class Soy(Beverage beverage) : CondimentDecorator(beverage) {
    public override string Description => $"{Beverage.Description}, Soy";
    public override double Cost() => Beverage.Cost() + 0.15;
}

public class Whip(Beverage beverage) : CondimentDecorator(beverage) {
    public override string Description => $"{Beverage.Description}, Whipped";
    public override double Cost() => Beverage.Cost() + 0.10;
}