home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.lang.c++
- Path: sparky!uunet!mole-end!mat
- From: mat@uunet.uu.net!mole-end
- Subject: Re: Novice? question: Designing for multiple inheritance w/ templates
- Message-ID: <1992Jul25.065523.3855@uunet.uu.net!mole-end>
- Summary: Problem Domain/Solution Domain
- Organization: :
- References: <1992Jul9.144630.10863@clpd.kodak.com> <1992Jul23.175814.15356@ucc.su.OZ.AU>
- Date: Sat, 25 Jul 1992 06:55:23 GMT
- Lines: 59
-
- In article <1992Jul23.175814.15356@ucc.su.OZ.AU>, maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
- > In article <1992Jul21.131054.20622@mole-end> mat@mole-end writes:
- > >In article <1992Jul20.152931.8037@ucc.su.OZ.AU>, maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
- > >> In article <1992Jul19.233851.15525@mole-end> mat@mole-end writes:
- > >>
- > >> >... From what I can tell, virtual inheritance is principally useful
- > >> >for importing what might be called `object representation behavior,'
- > >> >e.g. printability, special allocation and deallocation, etc.--things
- > >> >that are related to the representation OF the object, rather than to
- > >> >what the object itself represents.
-
- > >> Quite the opposite I find. Its prinicple use is in
- > >> deriving new abstractions from old.
- > >> ...
-
- > >> A new optimisation technique (like caching) can be
- > >> hooked in, on an object by object basis, at construction time.
-
- > >This is exactly what I was saying. The thing added by Virtual MI is added
- > >not for the sake of what the class represents, but for the sake of the
- > >class representation. ...
-
- > >Or do I misunderstand you completely?
-
- > Maybe I misunderstand.
-
- > IMHO: ALMOST ALL derivation should be public, and ALMOST ALL
- > public derivation should be virtual. Inheritance of an abstract
- > base class should be virtual and public even more often than almost
- > all :-).
-
- > When using mixins, the abstractions are derived, using
- > MI, from each other. They're the "problem domain" stuff aren't they?
-
- No, the examples you give are especially solution-domain. They come from
- programming technology and express programming-type concepts applied to
- programmed objects.
-
- Problem-domain stuff includes most of the examples in the popular OO
- texts, things that are expressed as `is-a' or `is-a-kind-of-a,' e.g.
- `A hardcover book is a kind of a book' (derive hardcover book from
- book), `A salaried employee is a kind of employee,' (derive salaried
- employee from employee), `A gravel road is a kind of road,' (derive
- gravel road from road).
-
- Is it possible to program with mixins for the problem domain? Yes, it is.
- Is the result malleable? I suspect not. I haven't examined any large
- model built that way, so I'm not sure. I rather suspect that some of the
- inheritance links that get built that way should be `part-of' links
- (bi-directional `has-a' links between objects collaborating to implement
- the functionality of the object representing the `whole').
-
- This is drifting off into abstract talk; we are better off with examples
- and with class-relationship or object-relationship diagrams before us.
- --
- (This man's opinions are his own.)
- From mole-end Mark Terribile
-
- uunet!mole-end!mat, Somewhere in Matawan, NJ
-