What Jim is saying is that there is nothing wrong with creating a container class with controls as long as the controls are subclassed from their own parent (as opposed to base) classes. Therefore, the last class in the heirarchy (the concrete class Jim refers to) is the one named in CREATEOBJECT or NEWOBJECT.

And I'll be the first to admit that I don't always follow this guideline with small to intermediate applications. My bad :-)


>>This issue is one of confusing the two processes of inheritance and composition. While each of them is a very powerfull paradigm in OO they conflict with each other when they are intermixed. Composition is the last thing that should be done before using the class to create an object. Inheritance is something that is part of the class design process, that is it is used to create a hierarchy of classes that can be then used in composing finished objects. Once one has done composition, further subclassing introduces complexities that are better avoided.
>>
>>It is not difficult, and in fact makes specialization easier, to avoid composition until the concrete class level, that is the last class level before creating the object.
>
>I agree (mostly I think) with what you are saying- and I am certainly up on the principles involved - but there is a different perspective.
>
>Sometimes (not always), I look at a contained objects as a PART of the class - a button for example in a container - I can logically perceive as just as much a part of the class as the container's methods and properties. This is one big reason with why I have a HUGE gripe with buttons not being able to access protected or hidden properties of the container class they are in. To me - those buttons ARE part of the class definition from a virtual standpoint - just as much as any method in the class itself - (notwithstanding the technicalities - which I do understand quite well.)