Introduction to Design Patterns for Flash and Flex by Joseph Balderson

Introduction to Design Patterns for Flash and Flex Presented by Joseph Balderson TodCon 2007, June 11-13 2007

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]

Introduction to Design Patterns for Flash and Flex

Once upon a timeline…

A nightmare was upon the land…

(WHEW!!!)

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)

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 ;)

The solution?

The solution?

OOP.

The solution?

OOP.

(Object-Oriented Programming)

And the timeline was so healed…

…through the magic of

Encapsulation

(wrapping functionality in an object)

Encapsulation

Abstraction

(encapsulating what changes)

… through the magic of

Encapsulation

Abstraction

(encapsulating what changes)

Inheritance

(subclassing)

But this can still lead to spaghetti code…

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

What to do?

What to do?

We need to find ways that classes & class objects can relate to each other without:

What to do?

Tight coupling of objects/components

What to do?

Tight coupling of objects/components

Programming to specific implementations

Solution:

Design Patterns

What is a “Design Pattern”?

A Design Pattern is a way of organizing a system of classes in a way that solves a particular programming problem.

We call these “Patterns”

in programming “Design”

because these solutions

solve commonly found problems

in OOP programming .

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

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>

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("button event method scope = "+this);

}

}

Solution:

We need an object to encapsulate and "re-route" 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("button event method scope = "+this);

}

}

That “solution” is called the Proxy Pattern .

A proxy class provides a surrogate, or “stands in” for another object to control access to it.

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. "this"), submitPress is scoped to mcApplication , and not btnSubmit .

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.

before

after

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.

Situation:

Need a "global class" 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.

Situation:

Need a "global class" 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.

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:

Problem:

Static methods cannot be subclassed

Problem:

Behaviour management may be limited by programming exclusively to static members within the class

Problem:

Behaviour management may be limited by programming exclusively to static members within the class

Static classes are usually referred to as "helper" or "utility" classes that encapsulate relatively simple behaviour

Solution:

Create a class which can only have one instance, which will manage our “global” data and behaviours.

Huh?

Huh?

How do we create a class which can only have one instance?

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 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.

Here, we encapsulate the “global” functionality of the Box class into a BoxManager class, which manages its own singular instance creation & access.

A typical Singleton example:

Our singleton class also uses the Factory Method Pattern .

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.

Becoming a Patterns Ninja

Design Principles:

A class should only have one major sphere of responsibility.

Design Principles:

Encapsulate what varies

Design Principles:

… so that you can alter or extend the parts that vary without affecting those that don’t.

Design Principles:

… 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.

Design Principles:

All Design Patterns provide a way to let some parts of a system of classes vary independantly of all other parts.

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.

Problem:

Using “event handlers“ or data binding tighly couples components together, so that changing instance names or adding functionality breaks the application.

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.

Design Principle:

Strive for loosely coupled object interaction.

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.

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.

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” :)

Intro to UML

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

Understanding Class Relationships

Dependancy

“ uses” relationship

a class that relies on the initialization of another class for its behaviour

And here’s what a real-world UML diagram with design patterns looks like…

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]

And now for something completely different…

Introduction to Design Patterns for Flash and Flex by Joseph Balderson

3 comments

Notes on slide 1

19 Favorites

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

More by user

More info about this document

Categories

Tags

Tags

Introduction to Design Patterns for Flash and Flex by Joseph Balderson

3 comments

Notes on slide 1

19 Favorites

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

Related Presentations

More by user

More info about this document

Categories

Tags

Tags