Robert Park wrote:
On Sun, Jan 30, 2011 at 3:16 PM, Roberto Cavada <roboo...@gmail.com> wrote:
On Sat, 2011-01-29 at 23:22 -0700, Robert Park wrote:
[...]
But I just can't shake this feeling that having a class to represent
just the GUI when it's already inside of a module is somehow
redundant. There will only ever be one instance of that class. What
good is that?
The fact that classes can be instantiated multiple times is not the
(only) reason for having classes. Inheritance and polymorphism give the
real sense to OOP - IMO - and having information hidden into hierarchies
and relations make the design easy to understand, extend, maintain, etc.
Ok, but I'm asking if the module itself provides the same "heirarchies
and relations" that I'm getting from the class. That is, when my
No, you don't have inheritance with modules.
entire project was in one file, it made sense to have the class for
it's encapsulation, but now that the other classes are in other files,
the module _itself_ is providing the same encapsulation that the class
was giving me, and is thus redundant.
Sort of, indeed.
That holds, until you add a second window, or you create custom widgets that you use in your
application GUI.
(At least, that is where I'd expect those things.)
My point with that example was not that the second version was better,
but that they were so similar that it proves that the module itself is
"good enough" and that I don't actually benefit from having this
particular class inside a module.
One concept you may want to keep is that 'import xyz' does nothing except
importing.
If you perform assignments at toplevel, importing has side effects.
For normal execution this is not a problem, for debugging it may be useful to have to explicitly
call setup, like you have in __init__(self).
Ok, but how does having module top-level functions instead of class
instance methods (for a class that can only be instantiated once) make
any difference? Either way there is a rigid API that I can be held to
For your case, it matters very little. The question is mostly when do you move the code one level
deeper, now, or when you want to extend the program.
The disadvantage of the latter is that you first need to do refactoring before you can extend. Since
that may happen after 2 years, it means you then have to understand what you did now.
Another consideration is other users, and/or other programs.
Other users will expect things to be one level deeper, so for their readability it is advisable to
code it that way.
In the same way, if you make more of these programs, chances are you are also going to make programs
where the code is one level deeper. That means that you will have two coding styles for the
top-level function instead of one, which is more difficult to manage correctly.
Well, one way that i'm attempting to make everything more readable is
by getting rid of the term "self" that is littered throughout my
program.
Every Python programmer understands what self means. He/she knows instantly
what you are doing.
Don't confuse 'short code' with 'readable code'. While related, they are not
the same thing.
Just my 2 cents,
Albert
_______________________________________________
pygtk mailing list pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/
