Re: [Flashcoders] Intro to OOP using ActionScript: patterns derail!
The "fancy names" are kind of useful actually. Most of the patterns I've learned but I didn't know the "fancy/official" names for them. This caused some confusion when talking with my coworker as he would be simply using the names instead of the concepts and I'd have to stop and figure out which one he meant, or I'd spend extra time explaining what I was talking about when I could have just said the name and been done with it. The names are useful as a common/shared way of referencing complex concepts. That said, the concepts are much more important than the names, as you can get by just fine with only the concepts, but fail miserably on with just the names. :) -Andy On 8/22/07, Ron Wheeler <[EMAIL PROTECTED]> wrote: > > > Dave Mennenoh wrote: > >>> How do you handle onLoad's famous scope? ... It is not magic or > >>> advanced. If a pattern was shown to a new programmer without giving > >>> it a fancy name, they would just accept it as the best way to do the > >>> task and would never give it moment's thought. > > > > Right. Delegate - ie Proxy. I agree. I wasn't saying patterns > > shouldn't be taught, or used - I doubt you could teach a Flash class > > these days without teaching Observer, but you might not ever call it > > that. In fact, I wonder who does call it that in a class? Actually, > > the more I think about it, I think for students it might be best not > > to call these patterns and just teach them. Then, once they know how > > to use them, tell them what they are. It's a bit like teaching > > encapsulation I think - if you just show your students how to write > > classes, and they see how classes work for organizing code, they will > > likely just use them. > > > > > That is what I have been saying from the start of this discussion. You > do not have to teach the fancy names. Just teach them to use proper > coding practices. OOP and Design Patterns are just names that we use to > group a bunch of best practices into theories so we can discuss the > theory and have a framework to critique code. I have a feeling that for > most of us, the word polymorphism is not much of a help and I see no > reason to even use the word on 14 year olds until the last week of class > and only then as a warning that someday someone might try to use it on > them in a discussion about design. > > Ron > > > > Dave - > > Head Developer > > http://www.blurredistinction.com > > Adobe Community Expert > > http://www.adobe.com/communities/experts/ > > ___ > > Flashcoders@chattyfig.figleaf.com > > To change your subscription options or search the archive: > > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders > > > > Brought to you by Fig Leaf Software > > Premier Authorized Adobe Consulting and Training > > http://www.figleaf.com > > http://training.figleaf.com > > > > > ___ > Flashcoders@chattyfig.figleaf.com > To change your subscription options or search the archive: > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders > > Brought to you by Fig Leaf Software > Premier Authorized Adobe Consulting and Training > http://www.figleaf.com > http://training.figleaf.com > ___ Flashcoders@chattyfig.figleaf.com To change your subscription options or search the archive: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Brought to you by Fig Leaf Software Premier Authorized Adobe Consulting and Training http://www.figleaf.com http://training.figleaf.com
Re: [Flashcoders] Intro to OOP using ActionScript: patterns derail!
Dave Mennenoh wrote: How do you handle onLoad's famous scope? ... It is not magic or advanced. If a pattern was shown to a new programmer without giving it a fancy name, they would just accept it as the best way to do the task and would never give it moment's thought. Right. Delegate - ie Proxy. I agree. I wasn't saying patterns shouldn't be taught, or used - I doubt you could teach a Flash class these days without teaching Observer, but you might not ever call it that. In fact, I wonder who does call it that in a class? Actually, the more I think about it, I think for students it might be best not to call these patterns and just teach them. Then, once they know how to use them, tell them what they are. It's a bit like teaching encapsulation I think - if you just show your students how to write classes, and they see how classes work for organizing code, they will likely just use them. That is what I have been saying from the start of this discussion. You do not have to teach the fancy names. Just teach them to use proper coding practices. OOP and Design Patterns are just names that we use to group a bunch of best practices into theories so we can discuss the theory and have a framework to critique code. I have a feeling that for most of us, the word polymorphism is not much of a help and I see no reason to even use the word on 14 year olds until the last week of class and only then as a warning that someday someone might try to use it on them in a discussion about design. Ron Dave - Head Developer http://www.blurredistinction.com Adobe Community Expert http://www.adobe.com/communities/experts/ ___ Flashcoders@chattyfig.figleaf.com To change your subscription options or search the archive: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Brought to you by Fig Leaf Software Premier Authorized Adobe Consulting and Training http://www.figleaf.com http://training.figleaf.com ___ Flashcoders@chattyfig.figleaf.com To change your subscription options or search the archive: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Brought to you by Fig Leaf Software Premier Authorized Adobe Consulting and Training http://www.figleaf.com http://training.figleaf.com
Re: [Flashcoders] Intro to OOP using ActionScript: patterns derail!
How do you handle onLoad's famous scope? ... It is not magic or advanced. If a pattern was shown to a new programmer without giving it a fancy name, they would just accept it as the best way to do the task and would never give it moment's thought. Right. Delegate - ie Proxy. I agree. I wasn't saying patterns shouldn't be taught, or used - I doubt you could teach a Flash class these days without teaching Observer, but you might not ever call it that. In fact, I wonder who does call it that in a class? Actually, the more I think about it, I think for students it might be best not to call these patterns and just teach them. Then, once they know how to use them, tell them what they are. It's a bit like teaching encapsulation I think - if you just show your students how to write classes, and they see how classes work for organizing code, they will likely just use them. Dave - Head Developer http://www.blurredistinction.com Adobe Community Expert http://www.adobe.com/communities/experts/ ___ Flashcoders@chattyfig.figleaf.com To change your subscription options or search the archive: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Brought to you by Fig Leaf Software Premier Authorized Adobe Consulting and Training http://www.figleaf.com http://training.figleaf.com
Re: [Flashcoders] Intro to OOP using ActionScript: patterns derail!
Alan MacDougall wrote: Dave Mennenoh wrote: Lots of programmers never need design patterns as they don't help much unless your architecting large apps, and lots of Flash programmers aren't developing those kinds of apps. Keeping your code organized however should be taught from day one and certain oop concepts are perfect for that. There are plenty of patterns that can apply well to small-scale projects: take undo. How would you cleanly support undo without Command? Other patterns like State, Adapter, Observer (especially to overcome the sadistic limitations of Flash's single callbacks -- MovieClip -- or single listeners -- MovieClipLoader)... all have uses even in a sporty little website tchotchke. Not every 'design pattern' is something like MVC or data mapping or dynamically-configured factories. On the other hand, I got your point. Design patterns are not some esoteric way of doing things. They are solutions to common programming situations that came up over and over again. For years, we all wrote our own way to accomplish these tasks. Finally some experienced guys looked at what they were doing and what other people were doing. They had a "Holy Sh*t" moment when they realized that they had 50 ways to do exactly the same thing. They looked at the various ways and tried to pick the best strategy. A design pattern book is not a road map to building an application. It is a collection of best practices for the tasks that come up all the time. It hard to imagine even a small program that could not use at least one of the design patterns that have been identified. It is hard to imagine a Flash program that would not be a candidate for several design patterns. A game with no Listener/Observer is hard to imagine. (How many onEnterFrames does it take to kill a program? ) How do you handle onLoad's famous scope? There is a design pattern for this and it gets explained every time a new flashcoder tries to read an XML file. You can probably find this in the archives once every 2 weeks. They do not call it a Design Pattern but it is. If you doubt the usefulness of Design Patterns, read Head First Design Patterns. You will read each section and sometimes be amazed at the simplicity of the solution and wonder why you never figured this out. In other sections you will say "What is the big deal? I do it like this all the time." It is not magic or advanced. If a pattern was shown to a new programmer without giving it a fancy name, they would just accept it as the best way to do the task and would never give it moment's thought. If you were trying to get the class to build a game, you would be foolish not to explain the Observer pattern. It is very simple and the alternatives are often really ugly and overly complex and frustrate the best of us. Ron ___ Flashcoders@chattyfig.figleaf.com To change your subscription options or search the archive: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Brought to you by Fig Leaf Software Premier Authorized Adobe Consulting and Training http://www.figleaf.com http://training.figleaf.com ___ Flashcoders@chattyfig.figleaf.com To change your subscription options or search the archive: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Brought to you by Fig Leaf Software Premier Authorized Adobe Consulting and Training http://www.figleaf.com http://training.figleaf.com
Re: [Flashcoders] Intro to OOP using ActionScript: patterns derail!
Dave Mennenoh wrote: Lots of programmers never need design patterns as they don't help much unless your architecting large apps, and lots of Flash programmers aren't developing those kinds of apps. Keeping your code organized however should be taught from day one and certain oop concepts are perfect for that. There are plenty of patterns that can apply well to small-scale projects: take undo. How would you cleanly support undo without Command? Other patterns like State, Adapter, Observer (especially to overcome the sadistic limitations of Flash's single callbacks -- MovieClip -- or single listeners -- MovieClipLoader)... all have uses even in a sporty little website tchotchke. Not every 'design pattern' is something like MVC or data mapping or dynamically-configured factories. On the other hand, I got your point. ___ Flashcoders@chattyfig.figleaf.com To change your subscription options or search the archive: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Brought to you by Fig Leaf Software Premier Authorized Adobe Consulting and Training http://www.figleaf.com http://training.figleaf.com
