Hi Sebastian, Thanks for the overview, no objections with Commands from me, that is for sure : ). So as for the controller, is that basically an event mapper for you, or an 'event bundler' for commands, or maybe there is more you do in there? What kind of advantages do you find with having it separated from the model like that? Is it for organization, or reuse, or maybe your model is more for pure state data..? Also, not sure if I got that right, but are you keeping track of who is subscribing to events as well? (I don't do that, but I have a lot of utility code that tracks that kind of thing down on dispose -- maybe formally keeping track of that is a better solution..? hmm).
As for maintaining code, I totally agree that MVC would mean you are at least at a reasonable/high level of code.. I had two projects in the last year that were a *mess* of garbled timeline code that needed fixing and scaling - ugh, that almost broke my sanity. My negative experiences with 'over-patterning' are more from Java -- where certainly the code was solid in the normal sense, just I found the philosophy hard to swallow as it got extreme. Ok, it actaully made me really really mad and eventually I had stop to do something else : ). I'm not sure if some people are more comfortable with that kind of thing, or if it was just made by people who think their crap is golden (honestly I'm still torn and undecided on that one). I sometimes think there are a whole bunch of "real deal Flash applications" that I'm missing. Certainly you can go far with solid design, and anything is possible with flash now -- I should probably spend more time looking around for that kind of thing. Oh, have to say, your comment on exceptions (so true) really brought me back to Antlr - where exceptions were used for flow control in the generated code. It was the worst thing in the world to sift through. It was a classic example of overdoing a good thing, in order to make it a bad thing. I'm sure it is better now, and I guess that is how we learn the limits of these things, but it still hurts when it bites you : ). Cheers, Robin -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of sebastian Sent: Tuesday, October 21, 2008 12:31 PM To: Open Source Flash Mailing List Subject: Re: [osflash] Q:Basic AS3 MVC question 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 _______________________________________________ osflash mailing list [email protected] http://osflash.org/mailman/listinfo/osflash_osflash.org
