77 lines
2.8 KiB
C#
77 lines
2.8 KiB
C#
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;
|
|
} |