The method, 'OnFileNew' is called thusly:
def menuData(self):
return (('&File',
('&New \tCtrl-N', 'Create a new project', self.OnFileNew),
...
I'm obviously referencing the method incorrectly, but I don't see my
error. A pointer would be very helpful.
I'm not sure without seeing all the code, but maybe you are trying to implement it the way it could be done in C++, where the methods of a class can be spread across several source files. Can't be done in Python;
That's not entirely true: you just can't call them quite the same way. For example, from the above:
def menuData(self):
return (('&File',
('&New \tCtrl-N', 'Create a new project', self.OnFileNew),
"self.InfileNew" means that InFileNew is a member of this class (self). If you had written:
def menuData(self):
return (('&File',
('&New \tCtrl-N',
'Create a new project',
MethodsModule.OnFileNew),
it way have worked.
However, the main point is true -- you generally don't want to do that, methods belong in the class that they are used in -- that's why they are called methods, rather than functions. In the above, I suspect that OnfileNew belongs in the Frame subclass you're writing -- that's where menu handlers usually go.
It's still not totally clear why you are trying to re-factor in this way, but I suspect it's to follow the DRY (Don't Repeat Yourself) principle. This is a good instinct. If you find yourself writing the same code in more than one place -- it's time for a refactor.
What I'm guessing is that you have a few classes that all share similar methods, so you tried to put those in their own file. That can be done but it's not the OO way to do it. The OO way is subclassing. If you have a bunch of notebook pages, they should probably all be derived from the same class -- the methods common to all of them go there, and that superclass can be defined in it's own module, if you like.
If things get more complicated, it could be time for multiple inheritance and mix-ins. If you google mix-ins, you'll probably get lots of stuff, but here's quick explanation:
There are times when you have a bunch of classes which share some of the same functionality, but not all. I finally got this when I tried to apply DRY to wx.lib.floatcanvas, so I'll use that as an example:
All the objects you might want to draw on the screen are derived from DrawObject. This class holds common functionality for all kinds of shapes. However, I found that there are multiple types of objects, all with overlapping functionality: For instance, some have only a line (lines, polylines), some have both a line and a fill ( circles, polygons, rectangles). Some have their position defined in terms of a single (X,Y) point (circles, text), some by a set of points (Polygons, polylines). To accommodate this, I set up a bunch of mixins - classes that don't do anything by themselves, but provide methods that are comon to more than one, but not all of the DrawObjects:
PointsObjectMixin
LineOnlyMixin
LineAndFillMixin
etc, etc.
Now to make a new kind of DrawObject, you can jsut piece together the functionality required, and most of the work is done with the mixins. For example, the Line class has just two of its own methods:
class Line(DrawObject,PointsObjectMixin,LineOnlyMixin):
def __init__(self,Points,
LineColor = "Black",
LineStyle = "Solid",
LineWidth = 1,
InForeground = False):
DrawObject.__init__(self, InForeground)
...
def _Draw(self, dc , WorldToPixel, ScaleWorldToPixel, HTdc=None):
...
- I hope that helps,
-Chris
···
--
Christopher Barker, Ph.D.
Oceanographer
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker@noaa.gov