My Singleton Template

<br /> package<br /> {<br /> import flash.display.MovieClip;<br /> <br /> public class Singleton<br /> {<br /> private static var _instance:Singleton;<br /> <br /> public static var _symbol:MovieClip;<br /> <br /> public function Singleton( enforcer:SingletonEnforcer )<br /> {<br /> }<br /> <br /> public static function get instance():Singleton<br /> {<br /> if( _instance == null)<br /> {<br /> _instance = new Singleton( new SingletonEnforcer() );<br /> _instance.initialize();<br /> }<br /> return _instance;<br /> }<br /> <br /> private function initialize():void<br /> { <br /> }<br /> <br /> public function destroy():void<br /> {<br /> }<br /> }<br /> }<br /> class SingletonEnforcer{}<br /> <br />

Thinking in Commands

A series of good articles.

Thinking in Commands (1/2)

Thinking in Commands (2/2)

Loading Data with Commands

Managing Sound with Commands

Dependency Injection

http://martinfowler.com/articles/injection.html

http://en.wikipedia.org/wiki/Dependency_injection

http://msdn.microsoft.com/en-us/library/ff649378.aspx

http://msdn.microsoft.com/en-us/magazine/cc163739.aspx

OO Design Principles

Design Principles
http://www.oodesign.com/design-principles.html

Identify the aspects of your application that vary and separate them from what stays the same.

Favor composition over inheritance.

Strive for loosely coupled designs between objects that interact.

Open-Closed Principle: Class should be open for extension, but closed for modification.

Dependency Inversion Principle: Depend upon abstractions. Do not depend upon concrete classes.

No variables should hold a reference to a concrete class.

No class should derive from a concrete class.

No method should override an implemented method of any of its base class.

Principle of Least Knowledge - talk only to your immediate friends. (It means when you are designing a system, for any object, be care of the number of classes it interacts with and also how it comes to interact with those classes.)

The Hollywood Principle: Don't call us, we'll call you.

A class should have only one reason to change.

Null Object: A null object is useful when you don't have a meaningful object to return, and yet you want to remove the responsibility for handling null from the client. (p.214, NoComand and p.372 Null Iterator)