Posted by Willem Bogaerts on 09/28/07 12:02

> I think I see what you mean, this does use 'extends' but doesn't add any
> new methods and uses same parent calling technique, so is
> decorat/subclass a very subtle difference, ie. if you add a new method
> not in the parent, it then basically becomes sub-classing?

It is the parent's responsibility to provide a cost. Hence the cost()
method. _HOW_ that cost is determined is an internal responsibility
(which may be met by delegating actions to other classes like
databases). All your subclasses have therefore the same responsibility:
provide a cost. Your subclasses "specialize" in the way this
responsibility is met.

The point of a decorator is that you may need to add responsibility to
an existing instance, so after you have given it a class. This is
impossible to do using subclasses.

> The thing I'm trying to get to really is how the database data should be
> structured and how the actual PHP code would utilise 'attribute' values
> such as 'white' and how the code would be structured in the PHP to then
> 'decorate' my product to find it's real value.
>
> eg. website may have 'Coat' product, might have drop-down 'White',
> 'Furry', in the db white may cost 1.00 more, if you want it furry, might
> be an extra 2.00

There are many ways to do that. Some people incorporate all the details
in the product name, some people use categories, versions, etc. You can
then either calculate the price at runtime with the given versions or
have price entries for all possibilities. I would suggest the latter,
because not all combinations thinkable are necessary deliverable.

Best regards
--
Willem Bogaerts

Application smith
Kratz B.V.
http://www.kratz.nl/

[Back to original message]