• Save
Introduction to Design Patterns for Flash and Flex by Joseph Balderson
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Introduction to Design Patterns for Flash and Flex by Joseph Balderson

on

  • 21,065 views

Visit http://www.communitymx.com/abstract.cfm?cid=90B1D to download a high-res PDF of this presentation. ...

Visit http://www.communitymx.com/abstract.cfm?cid=90B1D to download a high-res PDF of this presentation.

Synopsis:
Whether you consider yourself to be a Flash developer or a Flex programmer, eventually you will discover that projects have become too complex, too feature-rich, to rely exclusively on the Flash timeline, or on Flex MXML markup. Taking your project that extra step may require using actionscript class files and structured Object-Oriented Programming.

However, using OOP principles without a plan, without a way of structuring your classes, can very quickly lead to convoluted and unmanageable code. The solution is to use a tool called Design Patterns.

This session will dispel the myth that design patterns are only for geeks with PHDs, and explain how and why to use them in both Flash and Flex projects. Participants will come away with powerful tools to simplify and organize their coding projects to be better suited for efficiency and team development.

This is the powerpoint for my presentation at TodCon 2007 in Las Vegas, June 12, 2007.

Statistics

Views

Total Views
21,065
Views on SlideShare
20,941
Embed Views
124

Actions

Likes
41
Downloads
0
Comments
9

8 Embeds 124

http://www.slideshare.net 112
http://static.slidesharecdn.com 3
http://durga-technology4you.blogspot.com 2
http://www.slashdocs.com 2
http://durga-technology4you.blogspot.in 2
http://localhost 1
http://static.slideshare.net 1
http://translate.googleusercontent.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

15 of 9 Post a comment

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • Really very nice fast track presentation
    Are you sure you want to
    Your message goes here
    Processing…
  • Really very nice fast track presentation
    Are you sure you want to
    Your message goes here
    Processing…
  • nice presentation on design pattern. can u recommend me something to be a master of mvc triad pattern.

    Ravi Bhadauria
    ActionScript Programmer
    Are you sure you want to
    Your message goes here
    Processing…
  • brilliant PPT...crisp and helped me understand the various design patterns easily!!! thanks a bunch!!
    Are you sure you want to
    Your message goes here
    Processing…
  • 使用设计模式的好文章
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Introduction to Design Patterns for Flash and Flex by Joseph Balderson Presentation Transcript

  • 1. Introduction to Design Patterns for Flash and Flex Presented by Joseph Balderson TodCon 2007, June 11-13 2007
  • 2. Hurry Up And Code: Power Shortcuts for Flash & Flex Developers
    • Who is Joseph Balderson ? (aka ‘joeflash’)
      • Flash Platform Developer
      • Adobe Certified Trainer
      • Author & Community MX Partner
      • Consultant with New Toronto Group
      • email: [email_address]
  • 3. Introduction to Design Patterns for Flash and Flex
    • Once upon a timeline…
  • 4. Introduction to Design Patterns for Flash and Flex
    • A nightmare was upon the land…
  • 5. Introduction to Design Patterns for Flash and Flex
    • A nightmare was upon the land…
  • 6. Introduction to Design Patterns for Flash and Flex
    • A nightmare was upon the land…
  • 7. Introduction to Design Patterns for Flash and Flex
    • A nightmare was upon the land…
  • 8. Introduction to Design Patterns for Flash and Flex
    • A nightmare was upon the land…
  • 9. Introduction to Design Patterns for Flash and Flex
    • A nightmare was upon the land…
  • 10. Introduction to Design Patterns for Flash and Flex
    • A nightmare was upon the land…
  • 11. Introduction to Design Patterns for Flash and Flex
    • A nightmare was upon the land…
  • 12. Introduction to Design Patterns for Flash and Flex
    • (WHEW!!!)
  • 13. Introduction to Design Patterns for Flash and Flex
      • Specific code is difficult to find (wasting valuable time updating & debugging)
  • 14. Introduction to Design Patterns for Flash and Flex
      • Specific code is difficult to find (wasting valuable time updating & debugging)
      • Rigid code execution due to timeline linearity (leading to timing issues)
  • 15. Introduction to Design Patterns for Flash and Flex
      • Specific code is difficult to find (wasting valuable time updating & debugging)
      • Rigid code execution due to timeline linearity (leading to timing issues)
      • Tight linkage of assets and functionality
      • (impossible to change one thing without changing everything else)
  • 16. Introduction to Design Patterns for Flash and Flex
      • Specific code is difficult to find (wasting valuable time updating & debugging)
      • Rigid code execution due to timeline linearity (leading to timing issues)
      • Tight linkage of assets and functionality
      • (impossible to change one thing without changing everything else)
    • = “Spaghetti Code” (in the worst way)
    • = Large projects are impossible to maintain (without developing an ulcer ;)
  • 17. Introduction to Design Patterns for Flash and Flex
    • The solution?
  • 18. Introduction to Design Patterns for Flash and Flex
    • The solution?
    • OOP.
  • 19. Introduction to Design Patterns for Flash and Flex
    • The solution?
    • OOP.
    • (Object-Oriented Programming)
  • 20. Introduction to Design Patterns for Flash and Flex
    • And the timeline was so healed…
  • 21. Introduction to Design Patterns for Flash and Flex
    • …through the magic of
  • 22. Introduction to Design Patterns for Flash and Flex
    • …through the magic of
      • Encapsulation
        • (wrapping functionality in an object)
  • 23. Introduction to Design Patterns for Flash and Flex
    • …through the magic of
      • Encapsulation
        • (wrapping functionality in an object)
      • Abstraction
        • (encapsulating what changes)
  • 24. Introduction to Design Patterns for Flash and Flex
    • … through the magic of
      • Encapsulation
        • (wrapping functionality in an object)
      • Abstraction
        • (encapsulating what changes)
      • Inheritance
        • (subclassing)
  • 25. Introduction to Design Patterns for Flash and Flex
    • But this can still lead to spaghetti code…
  • 26. Introduction to Design Patterns for Flash and Flex
      • Classes encapsulate too much functionality
      • Dividing into further classes merely creates division, not clarity or maintainability
      • Components can still be tightly coupled
        • class myMCclassA {
        • class myMCclassA(){
        • this.myMCclassBinst.property = fixedValue;
        • }}
        • (component class objects are still directly referenced from within the MovieClip hierarchy)
      • Code becomes unruly after a certain level of complexity
  • 27. Introduction to Design Patterns for Flash and Flex
    • What to do?
  • 28. Introduction to Design Patterns for Flash and Flex
    • What to do?
    • We need to find ways that classes & class objects can relate to each other without:
  • 29. Introduction to Design Patterns for Flash and Flex
    • What to do?
    • We need to find ways that classes & class objects can relate to each other without:
      • Tight coupling of objects/components
  • 30. Introduction to Design Patterns for Flash and Flex
    • What to do?
    • We need to find ways that classes & class objects can relate to each other without:
      • Tight coupling of objects/components
      • Programming to specific implementations
  • 31. Introduction to Design Patterns for Flash and Flex
    • Solution:
    • Design Patterns
  • 32. Introduction to Design Patterns for Flash and Flex
    • What is a “Design Pattern”?
  • 33. Introduction to Design Patterns for Flash and Flex
    • A Design Pattern is a way of organizing a system of classes in a way that solves a particular programming problem.
  • 34. Introduction to Design Patterns for Flash and Flex
    • We call these “Patterns”
    • in programming “Design”
    • because these solutions
    • solve commonly found problems
    • in OOP programming .
  • 35. Introduction to Design Patterns for Flash and Flex
    • If you use OOP at all in Flash, or develop in Flex, you’re probably already using design patterns:
      • Observer
      • Proxy
      • Singleton
      • MVC (Model-View-Controller)
      • State
  • 36. Introduction to Design Patterns for Flash and Flex
    • If you code in OOP at all, you’re probably already using design patterns:
      • Observer: the event model
      • Proxy: mx.utils.Delegate , MovieClipLoader , <mx:Image>
      • Singleton: <mx:Application>
      • Model-View-Controller: <mx:Model> , <comp:MyComponent> , <mx:Application>
      • State: <mx:states>
  • 37. Introduction to Design Patterns for Flash and Flex
    • Problem: (in AS 2.0)
    • When defining an event handler method for a button, the method scope = event object, not the class instance.
    • class Application extends MovieClip {
    • private var btnSubmit:MovieClip;
    • private function onLoad():Void {
    • btnSubmit.onPress = submitPress;
    • }
    • private function submitPress(evtObj:Object):Void {
    • trace(&quot;button event method scope = &quot;+this);
    • }
    • }
  • 38. Introduction to Design Patterns for Flash and Flex
  • 39. Introduction to Design Patterns for Flash and Flex
    • Solution:
    • We need an object to encapsulate and &quot;re-route&quot; the declared scope of the function. (i.e. scope = object to which it belongs)
    • import mx.utils.Delegate;
    • class Application extends MovieClip {
    • private var btnSubmit:MovieClip;
    • private function onLoad():Void {
    • btnSubmit.onPress = Delegate.create(this,submitPress);
    • }
    • private function submitPress(evtObj:Object):Void {
    • trace(&quot;button event method scope = &quot;+this);
    • }
    • }
  • 40. Introduction to Design Patterns for Flash and Flex
  • 41. Introduction to Design Patterns for Flash and Flex
    • That “solution” is called the Proxy Pattern .
    • A proxy class provides a surrogate, or “stands in” for another object to control access to it.
  • 42. Introduction to Design Patterns for Flash and Flex
    • That “solution” is called the Proxy Pattern .
    • A proxy class provides a surrogate, or “stands in” for another object to control access to it.
    • By wrapping our submitPress object with the Delegate proxy class , passing a reference of mcApplication (i.e. &quot;this&quot;), submitPress is scoped to mcApplication , and not btnSubmit .
  • 43. Introduction to Design Patterns for Flash and Flex
    • Other examples of a proxy class :
      • MovieClipLoader (AS 2.0) : acts as a surrogate between the object calling the load action and the target clip loading the asset. The MovieClipLoader controls access to the target clip, and by doing so provides a more powerful set of tools for getting information from the load process.
  • 44. Introduction to Design Patterns for Flash and Flex
    • before
    after
  • 45. Introduction to Design Patterns for Flash and Flex
    • Other examples of a proxy class :
      • <mx:Image> (MXML): acts as a proxy between the UIComponent class instance (the parent tag) and the SWFLoader class instance which actually takes care of loading the asset behind the scenes.
  • 46. Introduction to Design Patterns for Flash and Flex
    • Situation:
    • Need a &quot;global class&quot; in the application that will be accessible anywhere. And we only need one class implementation, a single point of access to application data or behaviour management.
  • 47. Introduction to Design Patterns for Flash and Flex
    • Situation:
    • Need a &quot;global class&quot; in the application that will be accessible anywhere. And we only need one class implementation, a single point of access to application data or behaviour management.
    • Conclusion:
    • Use a static class, like Key , Math or Stage , and use it to store global data and behaviours.
  • 48. Introduction to Design Patterns for Flash and Flex
    • We could allow a Box class to store global data in static members, for keeping track of the number of instances created by the class:
  • 49. Introduction to Design Patterns for Flash and Flex
    • Problem:
      • Static methods cannot be subclassed
  • 50. Introduction to Design Patterns for Flash and Flex
    • Problem:
      • Static methods cannot be subclassed
      • Behaviour management may be limited by programming exclusively to static members within the class
  • 51. Introduction to Design Patterns for Flash and Flex
    • Problem:
      • Static methods cannot be subclassed
      • Behaviour management may be limited by programming exclusively to static members within the class
      • Static classes are usually referred to as &quot;helper&quot; or &quot;utility&quot; classes that encapsulate relatively simple behaviour
  • 52. Introduction to Design Patterns for Flash and Flex
    • Solution:
      • Create a class which can only have one instance, which will manage our “global” data and behaviours.
  • 53. Introduction to Design Patterns for Flash and Flex
    • Huh?
  • 54. Introduction to Design Patterns for Flash and Flex
    • Huh?
    • How do we create a class which can only have one instance?
  • 55. Introduction to Design Patterns for Flash and Flex
    • This “solution” is called the Singleton Pattern .
  • 56. Introduction to Design Patterns for Flash and Flex
    • This “solution” is called the Singleton Pattern .
    • There are three elements which make up a singleton class :
  • 57. Introduction to Design Patterns for Flash and Flex
    • This “solution” is called the Singleton Pattern .
    • There are three elements which make up a singleton class :
        • A private static property which holds a reference to the singular class.
  • 58. Introduction to Design Patterns for Flash and Flex
    • This “solution” is called the Singleton Pattern .
    • There are three elements which make up a singleton class :
        • A private static property which holds a reference to the singular class.
        • A public static method getInstance() which creates the single instance if non-existent, and returns a reference to the single instance.
  • 59. Introduction to Design Patterns for Flash and Flex
    • This “solution” is called the Singleton Pattern .
    • There are three elements which make up a singleton class :
        • A private static property which holds a reference to the singular class.
        • A public static method getInstance() which creates the single instance if non-existent, and returns a reference to the single instance.
        • A way of restricting class instantiation. In AS 2.0, we simply declare the class constructor as private. In AS 3.0 we cannot use private constructors, so we must resort to using a “private” class within the package declaration, which calls a runtime error to control instantiation.
  • 60. Introduction to Design Patterns for Flash and Flex
    • Here, we encapsulate the “global” functionality of the Box class into a BoxManager class, which manages its own singular instance creation & access.
  • 61. Introduction to Design Patterns for Flash and Flex
    • A typical Singleton example:
  • 62. Introduction to Design Patterns for Flash and Flex
    • Our singleton class also uses the Factory Method Pattern .
  • 63. Introduction to Design Patterns for Flash and Flex
    • Our singleton class also uses the Factory Method Pattern .
    • All “factories” encapsulate, or delegate the responsibility of object creation outside of its host, or owner class. Our singleton uses a Factory Method ( i.e. BallManager.createNewBall([owner]) ) to instantiate the Ball class.
  • 64. Introduction to Design Patterns for Flash and Flex
    • Becoming a Patterns Ninja
  • 65. Introduction to Design Patterns for Flash and Flex
    • Design Principles:
      • A class should only have one major sphere of responsibility.
  • 66. Introduction to Design Patterns for Flash and Flex
    • Design Principles:
      • A class should only have one major sphere of responsibility.
      • Encapsulate what varies
  • 67. Introduction to Design Patterns for Flash and Flex
    • Design Principles:
      • A class should only have one major sphere of responsibility.
      • Encapsulate what varies
        • … so that you can alter or extend the parts that vary without affecting those that don’t.
  • 68. Introduction to Design Patterns for Flash and Flex
    • Design Principles:
      • A class should only have one major sphere of responsibility.
      • Encapsulate what varies
        • … so that you can alter or extend the parts that vary without affecting those that don’t.
        • Now, if we wanted to add functionality to the Ball class, we could simply add new methods to the BallManager class instead, because the Ball class functionality does not vary.
  • 69. Introduction to Design Patterns for Flash and Flex
    • Design Principles:
    • All Design Patterns provide a way to let some parts of a system of classes vary independantly of all other parts.
  • 70. Introduction to Design Patterns for Flash and Flex
    • Design Principles:
    • All Design Patterns provide a way to let some parts of a system of classes vary independantly of all other parts.
      • Classes should be open for extension but closed for modification.
        • Use inheritance to extend functionality at runtime, vs. declaring a class as “dynamic” or adding to the prototype chain with Class.prototype.method because it breaks encapsulation.
  • 71. Introduction to Design Patterns for Flash and Flex
    • Problem:
    • Using “event handlers“ or data binding tighly couples components together, so that changing instance names or adding functionality breaks the application.
  • 72. Introduction to Design Patterns for Flash and Flex
    • Solution:
    • Create a broadcaster/listener system that decouples direct interaction.
    • The Observer Pattern defines a one-to-many (instead of a one-to-one) dependancy between a subject and its listeners so that many objects can respond to the same event without direct coupling.
  • 73. Introduction to Design Patterns for Flash and Flex
    • Design Principle:
    • Strive for loosely coupled object interaction.
  • 74. Introduction to Design Patterns for Flash and Flex
    • The Model-View-Controller (MVC) Composite Pattern
      • Model: repository of data from remote storage (DB, XML file, etc.). Almost always a singleton class.
      • View: presentation layer for the application (i.e. MXML components, UIComponents)
      • Controller: provides a separation of application logic from the View and decouples the View from the Model.
  • 75. Introduction to Design Patterns for Flash and Flex
    • Advantages:
      • By decoupling the View from the Controller , we can add functionality to our application without modifying the display components.
      • By decoupling the View from the Model , and the Model from the Controller , we can change data sources without affecting overall application functionality.
  • 76. Introduction to Design Patterns for Flash and Flex
  • 77. Introduction to Design Patterns for Flash and Flex
    • Design Principle:
    • A Compound Pattern is a combination of two or more patterns that solves a recurring problem. (Think of it as a “super pattern” :)
  • 78. Introduction to Design Patterns for Flash and Flex
    • Intro to UML
  • 79. Introduction to Design Patterns for Flash and Flex
    • Understanding Class Relationships
      • Inheritance
        • “ is-a” relationship
        • subclass assuming the behaviours of a superclass
      • Aggregation & Composition
        • “ has-a” relationship
        • instantiation of a class object – class “owns” the object
  • 80. Introduction to Design Patterns for Flash and Flex
    • Understanding Class Relationships
      • Dependancy
        • “ uses” relationship
        • a class that relies on the initialization of another class for its behaviour
  • 81. Introduction to Design Patterns for Flash and Flex
    • And here’s what a real-world UML diagram with design patterns looks like…
  • 82. Introduction to Design Patterns for Flash and Flex
  • 83. Hurry Up And Code: Power Shortcuts for Flash & Flex Developers
    • A Special Thanks To:
      • Mark Lapasa (aka ‘ false’) , Rick Mason (aka ‘egnaro’) from the Flash In TO user group
      • David Stiller (CMX partner)
      • Steve Schelter (CMX partner)
      • and all the gang at New Toronto Group
      • This presentation will be available at CommunityMX
      • email: [email_address]
  • 84. And now for something completely different…