>> Also, MVC's are made up Observer, Strategy, and Composite patterns. Those
>>need to be understood first.

There are many ways to use MVC, and you certainly don't have to understand 
those other patterns first.  Maybe how you use MVC.  You can use simpler forms 
of MVC without those patterns. 

>> But I am trying to understand why you would go through all that trouble, 
>> when calling the function in the parent, if it is a very small application 
>> unlikely to be expanded upon, is so much simpler?

Anthony - for very small applications, no, you wouldn't use a framework, and 
maybe not even a design pattern  - perhaps just a simple one.   You could call 
the funciton in the parent, sure, but know that it's not a good habit to get 
into, and will cause headaches in larger applications because you're doing what 
is known as tight coupling.  Loose coupled architecture, when possible without 
over-coding an app, is the way to go in most projects. Event dispatching and 
event listening is simple to implement anyway IMO.


Jason Merrill
Bank of America     Instructional Technology & Media   ·   GCIB & Staff Support 
L&LD

Interested in Flash Platform technologies?  Join the Bank of America Flash 
Platform Developer Community 
Interested in innovative ideas in Learning?  Check out the Innovative Learning 
Blog and subscribe.






-----Original Message-----
From: flashcoders-boun...@chattyfig.figleaf.com 
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Joel Stransky
Sent: Wednesday, January 07, 2009 6:38 PM
To: Flash Coders List
Subject: Re: [Flashcoders] design pattern diagrams...

@Jason
I'm talking about the oreilly book Actionscript 3.0 Design Patterns by
William Sanders and Chandima Cumaranatunge. Enter chapters are shifted off
the page but there are addendum on the site.

Also, MVC's are made up Observer, Strategy, and Composite patterns. Those
need to be understood first.


@Anthony,
>From what I've understood, if you aren't going to need to go back an
edit/extend the app frequently or work on a team, there really isn't much
benefit to using design patterns. They do however lend to re-using old
classes in new apps so you that you don't have to start from scratch each
time.

On Wed, Jan 7, 2009 at 6:16 PM, Anthony Pace <anthony.p...@utoronto.ca>wrote:

> But I am trying to understand why you would go through all that trouble,
> when calling the function in the parent, if it is a very small application
> unlikely to be expanded upon, is so much simpler?  maybe for code re-use in
> a bigger application sure; however, doesn't it seem weird that tightly woven
> and fast executing code is not prized anymore, and there is a preference for
> bloated object oriented frameworks?  All in the name of making the
> development cycle smaller and thus less costly; yet, what about increased
> file size issues and decreased performance?
>
> More objects and more event listeners == less performance and higher memory
> usage in my understanding.
>
>
>
>
> Ron Wheeler wrote:
>
>> Head First Design Patterns is very easy to pick up. No typos, lots and
>> lots of pictures, illustrations and code examples.
>>
>> http://oreilly.com/catalog/9780596007126/?CMP=AFC-ak_book&ATT=Head+First+Design+Patterns
>>
>> http://www.headfirstlabs.com/books/hfdp/ for a quick overview and a
>> typical illustration
>>
>> http://oreilly.com/catalog/9780596007126/toc.pdf  Read the section on the
>> Observer Pattern. It might be what you are looking for.
>>
>> Merrill, Jason wrote:
>>
>>> I think just a quick answer to your questions which may help a lot is to
>>> check into understanding MVC - the Model-View-Controller design pattern.
>>>  Probably one of the most common pattern used and one that other coding
>>> design frameworks use as well for part of their operations.
>>>
>>> So there are also frameworks like Cairngorm which takes MVC and other
>>> patterns together and go a lot further, it has things like Commands to
>>> facilitate communication.  But simple MVC using event listeners and
>>> dispatchers is probably the best place to start to get what you want to do
>>> going.
>>>
>>>
>>> Jason Merrill
>>> Bank of America     Instructional Technology & Media   ·   GCIB & Staff
>>> Support L&LD
>>>
>>> Interested in Flash Platform technologies?  Join the Bank of America
>>> Flash Platform Developer Community Interested in innovative ideas in
>>> Learning?  Check out the Innovative Learning Blog and subscribe.
>>>
>>>
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: flashcoders-boun...@chattyfig.figleaf.com [mailto:
>>> flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Anthony Pace
>>> Sent: Wednesday, January 07, 2009 3:48 PM
>>> To: Flash Coders List
>>> Subject: [Flashcoders] design pattern diagrams...
>>>
>>> I am looking to get more info on the composition of design patterns and
>>> which ones are used most often in the corporate world.
>>>
>>> Diagrams accompanied by code examples would be awesome.  I have been able
>>> to find stuff in the past; yet, I really want to know what is generally
>>> preferred?
>>>
>>> I like to try and make things black box; however, it just seems illogical
>>> that things be black boxes all the time.
>>>
>>> when a person talks to another person the environment that they are in
>>> has to facilitate the communication; thus, if I have two objects
>>> instantiated in the same class and I want them to communicate with each
>>> other, I have to have a function in the main class or somewhere globally
>>> that allows those objects to communicate.
>>>
>>> How do I accomplish this without calling to the function in the parent?
>>> _______________________________________________
>>> Flashcoders mailing list
>>> Flashcoders@chattyfig.figleaf.com
>>> http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
>>>
>>> _______________________________________________
>>> Flashcoders mailing list
>>> Flashcoders@chattyfig.figleaf.com
>>> http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
>>>
>>>
>>>
>>
>> _______________________________________________
>> Flashcoders mailing list
>> Flashcoders@chattyfig.figleaf.com
>> http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
>>
>>
> _______________________________________________
> Flashcoders mailing list
> Flashcoders@chattyfig.figleaf.com
> http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
>



-- 
--Joel Stransky
stranskydesign.com
_______________________________________________
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

_______________________________________________
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Reply via email to