Spec, then design and then code. You are skipping the specification step
and trying to get into the design too fast.
First, figure out what your object should do. What are the things that
it knows and what can you ask it to do?
This should be a small number of things typically. At high levels, they
will each be very big things functionally.
These are the properties and the methods that are visible to the public.
If these properties and methods match up with a class that you already
have or can get, then you might consider using the pre-existing class as
a base that you can extend or a model for what you need. If not, you
have to write you own class from scratch.
Start with your idea about what your application will need to do with an
object that knows something about graphs. Think about how you want to
instantiate this object (ie. what do you want to tell the object about
the universe at the moment of its creation.).
As you get into the design of the class, you will find that it needs
lower level objects to carry some of the information that it needs to
keep and to perform part of the functions that it needs to
do(composition). These lower level objects will have things that they
know and a list of functions that the higher level object can ask it to
do to help get its work done.
Once again these may match or not match existing classes.
Starting with an existing class with a name similar to what you need and
extending it is not a good way to go about the process. Looking for an
existing class that does almost everything that you need to implement an
object gives you an opportunity to extend it to meet you needs without
writing a lot of code.
You will always need composition to keep your application manageable. A
single class that does everything without importing any other classes
will be impossible to get working correctly. A well designed application
is going to have lots of classes and most of them will be very limited
in what they know or can do.
Inheritance is a bonus. It means that you have found a class that does
almost everything that you need to have done and all you have to do is
add a few small things that the original author did not think of or
discarded as not generally useful or decided could be best handled as
extensions to meet the needs of a particular programmer.
Ron
Millie Niss wrote:
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
_______________________________________________
[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
