Re: Clean Object Class Design -- What is it?

From: Jesper Ladegaard <jla_at_pine.dk>
Date: Thu, 26 Jul 2001 11:29:13 +0200
Message-ID: <3b5fe284$0$737$edfadb0f_at_dspool01.news.tele.dk>


"Lee Fesperman" <firstsql_at_ix.netcom.com> wrote in message

> In all the OO systems I've seen, everything is built with single direction
 linking -
> (pointers, references, composite objects). Inheritance is even worse; it
 is purely
> hierachical.

I 100% agree, the traditional way of doing "classification" in OO (using static class constructs) is sure not good enough!

Dirk Riehle and Thomas Gross has created a really great paper (IMO) where they describe how to use roles and roletypes to solve this problem.

The paper is free to download from Dirk Riehle's website. http://www.riehle.org/papers/1998/oopsla-1998.html

Also In PLOP 4 book there is the RoleObject pattern. Which is also a very nice way to overcome some of the damm-my-class-is-to-static kind of problems. It's one of my favorite patterns :-)

> That's fine for programmers who are used to it and don't have any better
 tools anyway,
> but a non-programmer wants to get from customer to invoice or from invoice
 to customer
> without having to know you must a different link/technique/concept for one
 direction
> versus the other.

Yes exactly, this is one the problems we're fiddling around with also!

IMO the problem is basically lack of meta-information. One of the best meta-architecture I've found that tries to solve this *nicely* is the MOF (Meta Object Facility) specification from OMG http://www.omg.org/technology/documents/formal/omg_modeling_specifications.h tm

It's really cool how they support both looking "down" the meta level's from a "meta-meta view point" and the usual "meta view" where the code knows about the meta-objects it's working with.

This way it's possible to create really dynamic meta-driven architectures that know how get from customer to invoice with hardcoding anything not even the domain model.

/Jesper Received on Thu Jul 26 2001 - 11:29:13 CEST

Original text of this message