>>In the object.action() paradigm, why can't my objects act on other objects? I'm doing a oDecorator.Lipstick(oAnyObjectRef). I am not keen on making objects which are in a feud and won't talk to each other. I want them to be able to have one comb hair and fasten the zipper on the other, simply because it's far less code to have oComber.Comb(oAny), than to teach every class how to comb its own hair.
>
>But not every class has hair, or the need to comb it. An OO design would have a class called Hair which includes a method called Comb(). That way any object of type Hair would be able to call this method, as would any object of a type derived from the Hair class. Write it once, done. Why should the Comb() method have to waste time checking object types?

Why should I have to waste time checking object types? I can't possibly be exhaustive, and I don't need to do that. See below.

> "Is the passed parameter a TextBox? Nope, move on. Is it a ComboBox? Nope, move on." Etc. until finally we arrive at the code that deals with type Hair.

Because none of my classes have hair at the moment (beards maybe, here and there...). So, I would have to visit each manually and teach it how to .grow("hair"). Which would be what, an additional member or property on each one of them - which would mean I would have to have a complete inventory of all possible classes which may need this, add code to each, and then someone adds something that wasn't on my list - bug, repeat... remember what it was first, then repeat. A proper decorator just applies its magic on anything that can take it, including the objects over which we don't have any influence except at runtime.

And the decorator doesn't actually need any permanent presence anywhere. It just pees around and goes away. If each class had to do that for itself, it has to, at least, have some code which will tell it to apply the .IHaveHair behavior to itself. Now with CLR you probably are capable of subclassing foreign classes, regardless of what they were written in (which probably inspired the eventhandler() and "implements" stuff in VFP), even when you have no clue whether the source was in Mandarin or Polish, which is good - but, again, you shouldn't need to do that. The object doesn't need to know anything, that's actually the beauty of the decorator. The fence doesn't need to know how to be painted, all you need is Tom Sawyer.

>I don't think either of us has convinced the other but this has been an interesting discussion. See you tomorrow....

I'll be here.