Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!gem.mps.ohio-state.edu!ginosko!uunet!mfci!hsi!wright
From: wright@hsi.UUCP (Gary Wright)
Newsgroups: comp.lang.c++
Subject: Re: When to make member functions?
Keywords: member functions, c++
Message-ID: <565@hsi86.hsi.UUCP>
Date: 29 Aug 89 12:58:54 GMT
References: <1267@pc.ecn.purdue.edu> <2506@fai.UUCP>
Reply-To: wright@hsi.com (Gary Wright)
Organization: Health Systems Intl., New Haven, CT.
Lines: 30

In article <2506@fai.UUCP> kurtl@fai.fai.com (Kurt Luoto) writes:
>Since there are so many things that you can do with a graph, it seems silly
>to encumber a simple graph class with all kinds of algorithmic functions.
>On the other hand, in other OOP languages you have no choice. E.g. in Eiffel,
>functions only exist as members of some class.  What is appropriate for C++?
>(Honest, I am not trying to start any flame wars here.)

1. Design an abstract graph class with no commitment to any 
   particular implementation.
2. Inherit from your abstract class, and define the implementation.
3. Inherit once more from a specific implementation of your graph
   class and add the computationally expensive algorithms at
   this step.  This step may also include adding state to the
   various nodes in the graph in order to implement some graph
   algorithms.

This is an over-simplification but my point is that there is no need to
design one and only one graph class.  By building your classes from
more primitive classes, you create future possibilities for reuse.  I
am also ignoring the fact that you will probably want a class that
describes nodes in the graph, and a class that describes the graph
itself.

I would suggest reading Chapter 12, "Graphs" in Software Components
with Ada by Grady Booch.  Regardless of what you think about Ada, Booch
does give some nice abstract definitions of various data structures in
his book.
-- 
Gary Wright 					...!uunet!hsi!wright
Health Systems International                    wright@hsi.com