Kevin Ollivier wrote:
Hi Mark,
[....]
The problem with using small samples for MVC is that it's hard to illustrate with a 100 line app exactly how one benefits from using MVC. (The sample you link to more just shows how you would go about MVC with wx.) MVC is all about ease of refactoring - you can quickly adjust to changes in your GUI layout, your business logic, etc. without having to re-write lots of your code just to update references from one object to another. Until you've had the pleasure of going through a bout of painful refactoring of code lacking MVC design, though, the light bulb won't really go off for you.
Say you did what you would naturally do, and put self.myMoney inside of View and bound the AddMoney and RemoveMoney handlers inside of the View's __init__ method, and had those methods directly manipulate self.myMoney. Then, after you've done that, users (or your clients / bosses) ask for a GraphView of the money, and a TimelineView and, oh, and they want a web-based API so that they can integrate it with Google Docs, and of course, they want it to be easy to install on servers which probably don't have wx installed. Does the initial design still seem like it will be up to the task? While in this very simple case it'd be easy to refactor, in a real world set up it would take considerably more effort. It's a LOT less painful to do the small extra effort of designing with MVC up front then it is to totally restructure your code to add it later. I know this because when I started wx coding I avoided both sizers and MVC, and I had to spend a lot of time undoing my old approach and re-writing a more robust one for the same code.
Until you come across a scenario like the above where the need for separation becomes obvious, MVC sounds like much ado about nothing. It's similar to sizers in that way. If you're coding on one platform and have relatively static resolutions to support, sizers are just an extra hassle, and pixel-perfect layout is faster and less to learn. Move your app to several different platforms and/or display resolutions, though, and you'll consider them a godsend and, if you have a decently large app that was written WITHOUT sizers, you'll kick yourself for not just taking the plunge and learning them.
The question Steven poses is, is it better to just let users learn how to do MVC design the hard way, or should wx samples and docs point them in the right direction? I tend to agree with Steven in this regards. As with sizers, I think it's okay to promote an approach where you may end up saying "you may not realize the need for this right now, but one day you'll find it makes a hard problem simple, and you'll really be glad you learned it". I think it would also indirectly lead to more users writing and contributing mixins, making adding advanced functionality quicker and easier.
We certainly should not force users to take any particular approach, but I think promoting good design is another issue entirely and I think users could really stand to benefit from seeing a different and more robust approach. Lots of people are not particular about how they code their app - look at how much wx code starts as straight copy and paste off of samples. Perhaps some users will reject the idea, heck I don't like the current wx approach now so you can never make everyone happy, but if we don't even show a more robust way in any real sense (except in an isolated sample here, or a wiki entry there), then we risk wx users who write major apps coming out with the impression that wx isn't really up to the job of creating robust and large-scale applications. And those are the people we need to build a community of long-term supporters.
Regards,
Kevin
Thanks Kevin for putting that into words - much better than I could
have. I've been pondering how to reply and convey my points clearly.
Yes, testing and refactoring are the main motives for this discussion.
By showing users "okay this is how we do it" we do show how to implement
the core logic easily, but these tend to develop into full-blown
applications where everything can just be a mess (I say this from
personal experience!)
There are many OO principles that discuss best practices and how to
miminise tight coupling between your modules. When there are lots of
code logic inside your event handlers, how can you unit test these to
ensure the code is behaving as expected? You'd have to create many
stub/mock code to represent your wx objects, as they are tightly coupled
to them. So you need to create mock Event objects for instance that
return dummy values at given times.
I agree with Robin and Kevin that the samples are well-suited towards
coupled code as it clarifies the code's intent, which is needed for
small samples for users to learn from. Perhaps we should create a wiki
section promoting code cleanliness and good practices. I find that
pubsub is great for this - while the pubsub "sendMessage" is essentially
equivalent to a direct method call, the lack of any explicit
dependencies between the modules makes for easier testing. If I use
"gui.change_tab" as my topic name, it does map to a method call, but
multiple message listeners can subscribe to that topic and handle the
change as appropriate. One message passed may end up starting a chain of
50 method calls inside various different modules.
This also means that there are less bugs - if a change is made, then
instead of tracking down all calls to gui.change_tab, we can just change
the relevant topic listeners. I've had many bugs due to making a new
change/feature bug forgetting to apply the change to one obscure place.
Law of Demeter - Wikipedia - The "Law of
Demeter/Principle of least knowledge" states how objects should have
small knowledge of their corresponding modules. for example, if module A
has an association with module B, and module B is associated to C, A
should never access C directly through B. Instead, it should call
methods on B that in turn accesses C.
This does lead to more delegate methods in your classes but the end
result is the client code that uses these classes has a nicer interface
to work with.
..phew! long posd!
···
On Jul 12, 2010, at 1:12 PM, Mark wrote:
--
Steven Sproat, BSc