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

> > >I know of metrics aimed at class design. People like Brian
> > >Henderson-Sellers to name one (see his book "Object-Oriented Metrics:
> > >Measures of Complexity", for example). Others include Ian Graham (he
> > >actually started an OO Metrics Club when he was with Swiss Bank some years
> > >ago - I went to the first meeting :) ). Their focus though is just on OO
> > >and not OODBs in particular. There are lots of other books and sources
> > >too, e.g.:
> >
> > I understand how one can use comparative metrics for things like complexity.
> > Is a "clean" design one that minimizes complexity?
>
> I guess complexity is one measure that could be used. But don't be fooled
> by the title I gave above. The book covers a range of issues associated
> with OO Metrics and good design. Unfortunately, I read the book quite a
> while ago and don't have it to hand to refresh my memory.

In the introduction page for the book, the author disclaims any reference to principles.

> O.K. It is probably a good idea to try and get yourself a book on OOA/D.
> Try here for some suggestions:
>
> http://ootips.org/
>
> Maybe also see the link "What Makes A Good Object-Oriented Design?":
> http://ootips.org/ood-principles.html

These have some interesting links. Thanks.

In particular, I found list at the latter link interesting:

• The Open/Closed Principle: Software entities (classes, modules, etc) should be open for extension, but closed for modification.

This principle basically boils down to encapsulation. In any case, physical independence requires internal representation to be independent of type.

• The Liskov Substitution Principle: Derived classes must be usable through the base class interface without the need for the user to know the difference. [See previous tip about LSP]

This principle basically boils down to polymorphism. I do not believe the relational model even requires a derivation relationship for polymorphism.

• The Dependency Inversion Principle: Details should depend upon abstractions. Abstractions should not depend upon details.

The relational model goes further and more explicitly by requiring physical and logical independence.

• The Interface Segregation Principle: Many client specific interfaces are better than one general purpose interface.

Logical independence implies this.

• The Reuse/Release Equivalency Principle: The granule of reuse is the same as the granule of release. Only components that are released through a tracking system can be effectively reused.

Logical and physical independence obviate the need for this principle in relational systems.

• The Common Closure Principle: Classes that change together, belong together.

I do not think this applies within the scope of a single database; although, it might apply across multiple databases. It also sounds more like practical heuristic than a principle.

• The Common Reuse Principle: Classes that aren't reused together should not be grouped together.

Again, this sounds more like a practical heuristic than a principle.

• The Acyclic Dependencies Principle: The dependency structure for released components must be a directed acyclic graph. There can be no cycles.

Is this a principle or a practical heuristic/rule? I think it is the latter.

I think the underlying principle might be "Do not burden the user with unecessary or needlessly difficult work."

• The Stable Dependencies Principle: Dependencies between released categories must run in the direction of stability. The dependee must be more stable than the depender.

Logical independence obviates the need for a similar heuristic in the relational model.

• The Stable Abstractions Principle: The more stable a class category is, the more it must consist of abstract classes. A completely stable category should consist of nothing but abstract classes.

Physical independence obviates the need for a similar heuristic in the relational model.

> > >There are some skilled OODB developers that I have met over the years, who
> > >understand some of the issues in designing classes and have developed
> > >rules-of-thumb, based upon their experiences. However, I haven't
> > >personally come across any techniques/methods, but would be interested as
> > >well if anyone has references.
> >
> > I already understand that the most intelligent and productive programmers
> > use better mental heuristics for improving solutions over their less
> > productive counterparts. Unfortunately, the majority of programmers are in
> > the latter group.
> >
> > I prefer to have well documented processes and principles to empower the
> > less productive. I suspect (quite strongly) that the underlying principles
> > in good OO design are the same as the underlying principles in good
> > Relational design.
>
> Bob, what kind of underlying priciples are you thinking of?

• Do not burden the user with unecessary or needlessly difficult work.
• Reduce and centralize the need for expert-level knowledge.
• Partition for performance.

> > >Off the top of my head, this might be worth
> > >a quick look at too:
> > >
> > >"Object-Oriented Database Design: What is the Difference with Relational
> > >Database Design":
> > >http://wwwiti.cs.uni-magdeburg.de/~schmitt/Publications/SaaConSch95.html
> >
> > Just from the abstract, I can already tell that the author falls prey to
> > many common misconceptions and fallacies.
>
> Could you please explain?

The author makes the mistake of assuming that additional syntax captures more semantics. The author makes the mistake of assuming that inheritance is required for polymorphism, and doesn't realise the consequences of physical independence. The author makes the mistake of assuming that OO has more to offer to modellers of data than modellers of data have to offer to OO. Received on Sun Jul 22 2001 - 01:29:48 CEST