Hi Robin, nice input. In my experience, separation of the controller become more critical once you start using a Command Pattern or when you simply have a lot of different gestures [user initiated actions].
When to use a command pattern or not depends so far on one of two needs: 1. the need to separate each 'action' into a standardized object. So that you can add/remove actions easily. 2. the need for 'undo' or 'redo' history arises or will arise in a future release. I've built pretty complex apps using MVC, and I must say that the separation of all 3 was very useful. The command class was also supplemented in my hand-over documentation with a UML diagram listing all of the events who was listening to it and for what purpose. Having all the commands in one place is essential when you have many classes all working on something different... in our project the View area of the software had more than 30 classes alone! I've also taken over other peoples code, and so far the most annoying aspect of that is seeing code where classes are not properly encapsulated. So one class might be doing 3 things instead of just 1 thing or within a class that is called it also does things like build user components, buttons and then animate them. This makes debugging a pain. But by far the most problematic is 'hacks', where exceptions are created to accommodate for unexpected changes or troubleshooting and then the exceptions are dealt with in a backhanded manner which means that every new additional feature is going to have to deal with exceptions created by previous problems... Just like in real life, the messier the house becomes, the messier it tends to get! [there is an acceleration effect in place] Every once in a while I like to take the time to re-factor code, encapsulate, separate, simplify etc. This 'house cleaning' chore not only makes your code easier to use in the current project, but it also gives you RE-USABLE code for other projects!!! Which will quadruple (or more) your resulting speed at writing new code; and thus it can't be over stated enough... Sebastian. Robin Debreuil wrote: > I think if you read again, most people aren't 'against patterns' (unless you > equate not being super enthusiastic with being against, not uncommon these > days). Eventually everything has a place. As for MVC, probably everyone > separates the model and view to some extent, and has since shortly after the > Turing Machine. The controller idea has always been the bastard stepchild of > the arrangement though. MVC like many other design patterns always assumes > you are going to have all these plugable options and things will be able to > magically interchange each part without problems. In reality you almost > never need to interchange things like that, and they will still break > assumptions when you do. So what you often end up with is a very > disconnected set of functionality, where it is hard to find and trace > through things. Of course if you write the code yourself it is a bit easier, > but stepping into someone else's code can be a genuine pain (which I've done > a few times). > > While I'm certainly not 'against' patterns, I do think there is a lot of > kool-aid drinking going on, that you have to be wary of. In general I find > the end result of patterns is often somewhat subverting things like static > typing -- sometimes that is what you need, but always that is something you > want to avoid if you can. Also they often hobble tools that can't pick up on > these metapatterns. Often they also make it very hard to find functionality > in code. They add a lot of noise, even with things like naming. These are > big deals. > > As for an alternative to MVC, I would suggest that in most projects it isn't > necessary to separate out the controller (much of that is already separated > into base classes, and what isn't generally is very specific and not > reusable or confusing). At one point you know what you need, you have lots > of organizational tools in you language and IDE, and there is absolutly no > need to abstract things further. Now please don't read that to mean never > use MVC, certainly there is a place. Usually though, it is used where it > just complifies things. Looking over the showcase at the pureMVC site for > examples, we have some websites, a video list, a task list, and a 15 slider > puzzle. I don't think you need a diagram like this > http://puremvc.org/component/option,com_wrapper/Itemid,34/ for a 15 slider > puzzle. Not a knock on anyone, I'm sure some people are comfortable using > it, some were learning more about it, and no doubt it is a solid > implementation. Just the idea that the world would be a better place if > everyone programmed like this is wrong, imo. > > Happy to hear counter arguments, esp wrt the controller part (I am easily > swayed by good examples : ). > >> "Why is this relevant to this list?" > > If "approaches to making Flash based software better" isn't relevant to this > list please let me know. Open source is the ultimate water cooler in the > software constrcution conversation, because you can debate with barrier free > working code. If this is more for announcments of OS products or something, > my bad and sorry, but then I clearly need a different list. > > Cheers, > Robin > > > > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Jaakko Manninen > Sent: Monday, October 20, 2008 5:23 PM > To: Open Source Flash Mailing List > Subject: Re: [osflash] Q:Basic AS3 MVC question > > Most of you seem to be against using the pattern on this list. So what would > you suggest doing instead of using MVC to achieve the same goals? MVC > certainly has its applications and will inherently help you organize things > well in those scenarios, given a proper implementation and use :) I'm sure > everyone understands that it doesn't apply universally to every software > project. > > Why is this relevant to this list? > > Jak > > On Tue, Oct 21, 2008 at 12:14 AM, Scott Langeberg <[EMAIL PROTECTED]> > wrote: >> I've shuddered to find classes typed: Model, View, Controller in >> projects I've been assigned to work on. ;) >> >> -Scott >> >> On Mon, Oct 20, 2008 at 3:28 PM, Robin Debreuil <[EMAIL PROTECTED]> > wrote: >>> For a horrifying look at over-pattern-itis, have a look at the >>> eclipse source code. Not to say patterns aren't useful, but they >>> aren't useful to the point that they should be treated as some high >>> level language construct (at least the ones that haven't migrated to >>> become that already : ). Often something being an 'approved pattern' >>> is treated as sufficient justification to use it, which of course is >>> crazy. It is something like saying, 'my code has no bugs because it >>> has unit tests'. >>> >>> Computer Science at any time is 60% fashion -- you have to constantly >>> be on guard for these things. >>> >>> Cheers, >>> Robin >>> >>> -----Original Message----- >>> From: [EMAIL PROTECTED] >>> [mailto:[EMAIL PROTECTED] On Behalf Of sebastian >>> Sent: Monday, October 20, 2008 2:20 PM >>> To: Open Source Flash Mailing List >>> Subject: Re: [osflash] Q:Basic AS3 MVC question >>> >>> Not sure I understood all that was written below, presumably due to >>> English not being your first language. >>> >>> The advantage of using good design patterns is to ensure >>> future-scalability and the modularity of your code. >>> >>> I often come across code that is half-object orientated; where one >>> class does two things instead of one, or the code is not properly > encapsulated. >>> Design patterns, or a micro-architecture such as pureMVC help us to >>> ensure that our code follows proper separation or encapsulation. >>> >>> Naturally an MVC architecture is not required on a simple site, nor >>> is a micro-architecture on a simple MVC implementation; but applied >>> to the right scale/type of project, it can make all the [long term] >>> difference. >>> And a common micro-architecture makes it easy to understand new >>> projects when old ones follow identical patterns. >>> >>> I'm curious as to why you have such strong negative feelings... have >>> you struggled with projects that are over-structured? >>> >>> Kind, >>> >>> Sebastian. >>> >>> iteratif wrote: >>>> The whole question is: is what you spent pureMVC because you >>>> perfectly mastered the MVC model or rather lack of knowledge on the > subject. >>>> Because the use of abusive patterns in the frameworks have no >>>> meaning, it proves the lack of knowledge about the subject. >>>> Otherwise the GoF would have done it a long time ago. >>>> >>>> These frameworks do live that those who create and be a shame not >>>> good enough for you anlgais in the show technically. >>>> >>>> Indeed this is not the patterns or even less frameworks that guide >>>> a project, these are the needs. So if a project does not recquire >>>> model MVC not need to implement ... when it was well understood and >>>> we understand the full meaning of object-oriented programming ... >>>> >>>> bonne continuation >>>> Iteratif >>>> >>>> >>>> _______________________________________________ >>>> osflash mailing list >>>> [email protected] >>>> http://osflash.org/mailman/listinfo/osflash_osflash.org >>>> >>> _______________________________________________ >>> osflash mailing list >>> [email protected] >>> http://osflash.org/mailman/listinfo/osflash_osflash.org >>> >>> >>> _______________________________________________ >>> osflash mailing list >>> [email protected] >>> http://osflash.org/mailman/listinfo/osflash_osflash.org >> >> >> -- >> : : ) Scott >> >> Helping your grandma on the interweb >> at: http://blog.criticalpile.com >> >> _______________________________________________ >> osflash mailing list >> [email protected] >> http://osflash.org/mailman/listinfo/osflash_osflash.org >> >> > > _______________________________________________ > osflash mailing list > [email protected] > http://osflash.org/mailman/listinfo/osflash_osflash.org > > > _______________________________________________ > osflash mailing list > [email protected] > http://osflash.org/mailman/listinfo/osflash_osflash.org > _______________________________________________ osflash mailing list [email protected] http://osflash.org/mailman/listinfo/osflash_osflash.org
