Steve
Steve
Steve Luke wrote:In this particular example, the correct pattern would probably be the 'Decorator'. The cookie is a lone class, and the ingredients are things that the cookie uses to modify itself.
Dennis Deems wrote:
Steve Luke wrote:In this particular example, the correct pattern would probably be the 'Decorator'. The cookie is a lone class, and the ingredients are things that the cookie uses to modify itself.
I disagree. The way I see it, Cookie is really an abstract concept that can be implemented a number of different ways. Oatmeal is one way of being a cookie, and Butter is another, very different way of being a cookie. There are myriad other, completely different ways of being a cookie: NoBake, Bar, Sandwich, Fortune. In contrast to the coffee example in HFDP, it seems to me there really isn't anything here to decorate. In that example, an undecorated object has utility -- it's a cup of coffee, and we can drink it. But here, without any decorators there is no cookie.
Steve
Steve
Steve Luke wrote:Other than the fact the implementation described above isn't really a decorator pattern (the traditional decorator uses wrappers and such, so an OatmealDecorator would take an instance of Cookie and add to it some change, rather than being passed to the Cookie to be acted on by the cookie): I still thing the decorator pattern (in its correct form) or the composition that I did above (and incorrectly called the decorator - don't know of the correct pattern name) both are more appropriate than making subclasses of Cookie.
The problem you mention (Dennis) about having many different ways of 'being' a Cookie is exactly the problem that both the composition technique and the decorator pattern address. There are many different, and independent ways the Cookie can be 'extended' and really there is little chance of predicting all possible combinations at initial development. You can have OatmealCookie, which would presumably extend Cookie. And OatmealRaisinCookie which extends OatmealCookie. You can have a CookieBar, and a NoBakeCookie. How about a NoBakeOatmealRaisinCookieBar? Trivial in terms of decorator or the composition, painful if you rely on inheritance.
You might have a hard time conceptualizing an undecorated Cookie, but that does not detract from the correctness of the pattern - in my opinion anyways.
Dennis Deems wrote:
Steve Luke wrote:In this particular example, the correct pattern would probably be the 'Decorator'. The cookie is a lone class, and the ingredients are things that the cookie uses to modify itself.
I disagree. The way I see it, Cookie is really an abstract concept that can be implemented a number of different ways. Oatmeal is one way of being a cookie, and Butter is another, very different way of being a cookie. There are myriad other, completely different ways of being a cookie: NoBake, Bar, Sandwich, Fortune. In contrast to the coffee example in HFDP, it seems to me there really isn't anything here to decorate. In that example, an undecorated object has utility -- it's a cup of coffee, and we can drink it. But here, without any decorators there is no cookie.
Steve
Steve
requirements wrote:HardContainers should have a defined volume. There should be a way to set the volume. There should be a way to update other classes when the volume changes.
The HardContainer does not care about the type of contents when calculating volume.
The SoftContainer has different means of calculating volume.
Steve
Did you see how Paul cut 87% off of his electric heat bill with 82 watts of micro heaters? |