> i have two classes in my program that use a global object > that is a socket connection. > ... code snipped > is there something tricky about passing this as a global object to > different modules that would need to use it?
Whiler its possible to use a global in this way its usually better to avoid global objects in a reusable component since otherwise it might clash with another global that the reuser already has. Its much better to use a parameter which can be provided by the user of the classes. In this case the socklet becomesc a parameter. A good place to put this parameter would be the init method of both your classes, where they would store a reference to it as an internal attribute. (remember that in Python all attributes are references so if you pass the same socket to both constructors both classes will point at the same socket). This approach also allows the user of your classes to suvbstitute any socketlike object that they mauy have, even their own bespoke version if needed. That greatly increases the flexibility of your code. > Or does this go along with what you wrote a while back about > having classes that depend on each other ? If you really must use a shared global then I would strongly consider putting both classes, the global variable and an initialisation function all in a single module. If however tyou can parameterise things as described then you need to consider whether anyone would be able to (and want to) use either of the classes without the other. If you always need them as a pair they still should go in one module, otherwise put them in separate modules. > One runs as a thread, the other responds to gui input. Does it respond to GUI input or just input? If it can be independant of the GUI (and you should really try hard to make it so) then its independant and best in its own module. The fact that the other runs in a thred is fairly irrelevant to this discussion, the real issue is whether it has hard coded dependencies on the other class. For example does it instantiate a copy within its methods? (in which case you must import the other module/class into this module) And more especially does it take an instance as a parameter of a method? (in which case the *re-user* must import the other module.) In the second case I'd say definitely put them in a single module, in the first case consider it, but it's not essential. I hope that makes sense, Alan G. On 12/31/06, Alan Gauld <[EMAIL PROTECTED]> wrote: "shawn bright" <[EMAIL PROTECTED]> wrote > Yes, the thing is getting to be a pain to deal with at this size, i > am > in-process of splitting out the classes into their own files. One thing to watch is that while its easy and tempting to create one file per class it's often better to keep dependant classes together. In other words if class A can only be used together with class B then it is often better to keep A and B in the same module. Anyone who needs B can import the module and anyone who needs A needs B too so it saves them having to import two modules. As in all things in programming a little bit of thought is often better than the first "obvious" strategy. Grady Booch described the above strategy by saying that "the unit of reuse is the category" (which in his OO notation was a set of related classes) and in Python that means the module. Regards, Alan G. _______________________________________________ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor ___________________________________________________________ New Yahoo! Mail is the ultimate force in competitive emailing. Find out more at the Yahoo! Mail Championships. Plus: play games and win prizes. http://uk.rd.yahoo.com/evt=44106/*http://mail.yahoo.net/uk
_______________________________________________ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
