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
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.
HTH,
Erik
(Over 90% of what I know about this stuff I learnt from Peter :-))
--
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/
_______________________________________________
coders mailing list
coders@slug.org.au
http://lists.slug.org.au/listinfo/coders
