Redesign of decorator pattern

[srgtrujillo]

I've opened this pull request to discuss the necessary changes so that the implemented example complies with the principles of the Decorator Pattern

#1

[tonilopezmr]

Oh my good lots asserts

[Cotel]

I've made some refactors and now IngredientDecorator makes use of by correctly (though it is not the most clever way to implement this example (Noodles could be an abstract class too and every noodles and ingredient only should need to define its cost reducing that way lines of code)).

I've detected a bug too. When showPrice() is called the price is shown correctly while noodles are not decorated or when they are decorated only by ingredients. But when the type changes to a sauce decorator it only returns the base price again because it has no calculateTotalCost() from ingredients decorators.

Does this mean we are not implementing the pattern correctly yet? If an object gets decorated it shouldn't lose its previous decorators isn't it?

[Cotel]

Then IngredientDecorator is not adding any behaviour 😵

[srgtrujillo]

I think with the fact of implementing the decorator function in each concrete case, it's already adding behaviour. What do you think about it?

[Cotel]

But If Noodles already has a method calculateTotalCost() then, every child that implements it modifies its behaviour. Noodles shouldn't have that method, it belongs to IngredientDecorator and the concrete decorators which will add that behaviour to Noodles.

[Cotel]

COST is a constant. It shouln't go in the constructor because you are opening it to change and we are not interested in that.

[srgtrujillo]

I think the keyword val make the constant COST inmutable.

[Cotel]

But you are placing the declaration in the constructor. You are giving the opportunity to set another COST when making a new instance.

[srgtrujillo]

I've done some tests and you're right. I have extracted the COST variable from the constructor to an immutable constant.

[tonilopezmr]

@srgtrujillo You still alive?