Hello,
Erik de Castro Lopo wrote:
> Adelle Hartley wrote:
>
>> I think this could be a great pattern for proprietary software, but I'd
>> granularize it based on features rather than devices - just declare an
>> application that inherits the features that the client has paid for or
>> that are part of the product sku being built.
>
> Hi Adelle,
>
> I hope you didn't misundertand Peters post.
>
> In short Peter's point was that (for instance) features of a GUI
> are not handled well by inheritance mechanisms. In particular,
> inheritance gives the derived class an is-a relationship to its
> base class when a has-a relationship would be better.
>
> For instance, a GUI class should very definitely not inherit a whole
> bunch of properties (ie have an is-a relationship). The problem is
> tha if you have C derived from B derived form A:
>
> C -> B -> A
>
> and now need to have something like C which doesn't have property
> B, your're stuck, you basically have to reimplement C as C' :
>
> C' -> A
Well, why wouldn't you be able to do this simply?
:if you define A as an interface with virtual functions then you can
structure your design like this:
A
^
|
-----------------
^ ^
| |
B C
------ -------
^ ^ ^ ^
B' B'' C' C''
with A holding all the common structures(functions, class variables
etcetera) and overloading those functions in subclasses as required.
For any changes/feature_improvements in the source, one only needs a
definition in A and overload it as required in B'/B''/C'/C'' or live
happily with the default implementation in A.
> A better solution for implementing something like properties is to
> make them member elements of the class (a has-a relationship).
> This can work particularly well if all of the properties can derive
> from a single base class (called say property) so that the GUI class
> can simply keep all of the properties in a single container of
> properties (std::list maybe) and run time type information takes
> care of the behaviour of each property in the list.
Yep. Single base class with multiple sub classes is the way to go and
majority of the toolkits/libraries use this model with single base
class holding all the common functions/properties (however, we are free
to overload them in our classes; but then this depends on the
function's visibility too).
(I've significantly twisted this discussion to denote a pattern instead :)
--
Cheers,
Ishwor Gurung
_______________________________________________
coders mailing list
coders@slug.org.au
http://lists.slug.org.au/listinfo/coders
