Re: Implementing weird kind of graph in C++
On Dec 13, 9:52 pm, mike3 <mike4...@yahoo.com> wrote:
[..]
So then I guess what I should do is have a regular graph class (perhaps
use the one from Boost) and then make a special "string manager" or somet=
hing
that provides the "string" functionality I'm looking for? E.g.:
[..]
Or string could be a separate class, but that could mean it could be used
outside a web, in which case there seem to be problems: if you could use =
it
on any old accessible graph, then if you go through the graph's add/ dele=
te
node functions (as opposed to the string's), there'd be no guarantees
the string would still work afterwards. Is that OK? It would seem that to
alleviate it you'd need more intimate connections between the graph & str=
ing
object.
And that's where my troubles appear -- how to do that in a non-"messy"
fashion. What to do? Just use the approach above? Does that "miss" a laye=
r
of abstraction since string is not its own class and all its stuff is han=
dled
by Web, and so be bug-inducing?
Notice, you are now at a completely different level of thinking about
your original problem. At first you mixed details of the
implementation, like pointers, into your considerations. Now you focus
on caring about how your classes should interact, i.e. the design
level. I consider this a progress.
In your prototype code you always consider constructing handlers, or
adding members that have class types defined externally to the class
you are setting up. Maybe it could help to review your design not to
consist of classes that manages / contains objects of other classes
exclusively. Instead, use class inheritance where appropriate.
The thing I do most of the time is asking myself, (1) should new class
A *be* a special case of existing class B, or (2) should class A
*have* one or more instances of class B. For the first case, I choose
inheritance, for the latter case members. This simple test is not a
dogma, many times you can do things the other way around just as well
or even better. I tend to get working programs by this approach, so it
can't be all bad.
In your problem, my stomach feeling tells me class Web is a special
case of a general graph. Therefore I believe its a good idea to derive
Web from one of the boost classes and provide its interface to the
public. This gives you the added benefit of all graph algorithms
available from boost immediately working with your class at no extra
cost. Overload any of the methods that need to do stuff special to
your Web class. This should take care of your worries about somebody
calling methods of your base class interface.
"String" is a different issue. A Web *has* strings, so here a book
keeping helper class may be a good approach. If you do not like to
export it outside of Web, just make it an embedded private class.
Maybe you should choose a better name because 'string' has a different
notion for other people that may add confusion.
So a very crunched (no proper C++ !) set up might be:
class Web : public boost::somegraphclass {
private:
class String { ... }; // describes one string in a web
std::vector<String> mystrings; // or other container, the strings
in *this* web
void BookKeepingMethod1();
void BookKeepingMethod2(); // also can wrap these in a handler
class
public:
void MyWebAlgorithm(); // your specialized public interface.
};
best,
MiB.