I am trying to design an application that will need a Graph object. For some
things, I need only a graph data structure (ie a set of nodes along with an
adjacency matrix that says which nodes are connected to which other nodes). In
other parts of the application, I will need a graph movie clip (GraphClip
object), in which there is a an icon (movieclip) for each node and the nodes
have coordinates on the screen and so forth. For this second kind of graph,
the nodes will be draggable and the edges and nodes will be selectable. I
already made this work in one big class but now I see I will want sometimes to
have only the data structure without the movieclips so I think I should break
the class in two.
The most obvious design would seem to use inheritance: Graphclip
extends Graph, but I was just reading a book on design patterns
("Design Patterns Explained" by Shalloway and Trott) which has a big
emphasis on using composition rather than inheritance, so this made me
think maybe that the GraphClip class should have a property that is a
Graph.
I envision needing graphs that need to interact with the user in different
ways. One kind needs draggable nodes where the edges follow alomg as you drag
(I did that). Another will need nodes you can click on to trigger some event.
Another might need the edges to be selectable, or the polygons formed by the
edges (this is for graphs whose edges do not cross, which was a problem I
posted about previously). The variations don't logically fall into a singfle
chain of inheritance since I might need a combination of features. I vaguely
recall that the Decorator Pattern deals with this, however, so that isn't what
really confuses me.
I become confused and my class diagram looks like spaghett when I start to try
to deal with the nodes. The nodes in the Graph don't need any data whatsoever:
all nodes in a mathematical graph are identical. The nodes (NodeClips) in the
GraphClip need to know where they are and what icon is used to display them.
Again, translating this stupidly into an OO design would use inheritance (the
nodes that have a position would inherit from the generic node type), but then
it gets confusing because GraphClips would need an array of NodeClips, whereas
Graphs could use plain Nodes. But if the GraphClip contained a Graph property,
then that Graph would either have to have NodeClips instead of plain Nodes, or
one would need a second array of NodeClips to store the node positions.
Yucch. The first way is confusing but possible to do since NodeClips are Nodes
and so you could construct a Graph that had NodeClips. The second thing
(duplicating the node array) is obviously bad. I
am sure the "correct" solution uses neither of these designs.
I sometimes find that every time I read a book on software architecture, it
messes me up and I design worse programs. The design patterns book is quite
good and as I read I felt I was understanding it. But when I went to start
designing a program after reading the book, I found myself more confused. I
don't think it is the book's fault -- it is good and quite clear -- but that
half-digested design advice mixed with half-understood new ideas make for worse
program architectures than one's previous more limited but well-worked
repertoire of design methods. Hopefully, after reading the book again or
taking more time to think the ideas through, I will actually benefit from
having read it. If I cannot do that, at least the bad effect should wear off
once I forget the book's advice...
Millie
(By the way, I used Grant Skinner's gModeler to draw possible class
diagrams and I was quite pleased with the way the diagrams printed
etc. I found it slightly hard to edit links, but otherwise the program
was quite easy to use.)
_______________________________________________
[email protected]
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com
