Introduction to Design Patterns for Flash and Flex by Joseph Balderson

Loading...

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

3 comments

Comments 1 - 3 of 3 previous next Post a comment

Post a comment
Embed Video
Edit your comment Cancel

19 Favorites

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…

+ Joseph BaldersonJoseph Balderson, 3 years ago

custom

7554 views, 19 favs, 2 embeds more stats

Visit http://www.communitymx.com/abstract.cfm?cid=9 more

More info about this document

© All Rights Reserved

Go to text version

  • Total Views 7554
    • 7552 on SlideShare
    • 2 from embeds
  • Comments 3
  • Favorites 19
  • Downloads 0
Most viewed embeds
  • 1 views on http://localhost
  • 1 views on http://static.slideshare.net

more

All embeds
  • 1 views on http://localhost
  • 1 views on http://static.slideshare.net

less

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate. If needed, use the feedback form to let us know more details.

Cancel
File a copyright complaint
Having problems? Go to our helpdesk?

Categories