Kent Johnson said unto the world upon 2005-02-11 11:34:In general I think this is a bad design. I try to avoid telling components about their parents in any kind of containment hierarchy. If the component knows about its parent, then the component can't be reused in a different context and it can't be tested without creating the expected context.
Is there another way you could accomplish what you want?
Kent
Hi,
thanks to everyone for responding. It hadn't occurred to me I could pass self to a class instantiation. So, that solves my issue given my original design intent: thanks.
As for Kent's question: I may have a better way now. I'd appreciate help deciding. So, if I may, I'll say a bit more about the problem domain. I've made the description as short as I know how.
The file format I am working with is from a `folding notebook' style of application (<www.treepad.com> if anyone is interested). It's a 2-pane editor/outliner. There is a tree of nodes with each with a (not necessarily unique) title, a unique id number, other metadata and an associated article (in plain text, html, or RTF [ugh!]). The file format also defines a header for the entire file.
I have a class TP_file, which, when instantiated, creates an Head object and, for each node, a Node object.
The program supports hyperlinks in the article text, both to other nodes (by unique id) and to external objects. Before posting this most recent question, I'd planed for the Node class to have a method that would scan the node's article, looking for text strings that match any node title and linkifying them. (I already know how to deal with already linkified instances of the string and cases where one string is the title of multiple nodes.) Since this method needs to know the titles of all Node objects, I thought I needed to make each Node aware of its TP_file object to fetch its nodes. (Hence my most recent question.) And, since it alters the article text of a Node, I thought it needed to be a method of the Node class.
But, while reflecting on Kent's question and thinking of how to describe my problem domain, I think I have a better idea now :-)
It still seems to me that the actual updating of the article should be a Node method (it is the Node object's article that is being updated, after all). Call it node_linkify. The new thought is to create two new methods for the TP_file class:
- One to build a dictionary with Node titles as keys and a list of the corresponding unique ids as values.
- Another to pass that list into a the node_linkify Node method, once for each Node object of the TP_file.
Does this seem like a reasonable approach given my description of the problem?
Yes. This is the kind of solution I look for - instead of having the Node class look 'outside' itself to find what it needs - and therefore have the Node class dependent on a particular context - have something poke the Node from the outside and give it the information it needs to do its job.
Do you see how this makes the Node more self-contained? For example you could write a unit test for node_linkify() that would just have to create a Node with some text and a helper dictionary. With the old design you would have to create several nodes and connect them in a Body.
It may not seem like a big deal, but in a larger program these cross-dependencies grow and knit the whole thing into an inseparable whole. I worked on a program where the data model was dependent on the GUI implementation classes (*very* bad idea). So to reuse the data model (to be able to access the data in a different program) you had to include the GUI classes!
A couple of notes about the general rule, though:
- In tree-structured data I often need the node objects to know about their parent. Navigating up the tree is often handy.
- In a GUI it can be challenging to figure out how to avoid telling the GUI classes about each other. For example if a button in one panel has to influence another panel. Usually I find a way but it gets a bit convoluted sometimes.
Thanks for the continued help -- it is most appreciated. I might just become an OOP programmer yet! ;-)
You're on your way!
Kent
Best to all,
Brian vdB
_______________________________________________ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
_______________________________________________ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
