Design Pattern - How to organize packages for decoupling externally loaded SWFs.

Here is a design pattern that will show you how the hierarchy should work when building a complicated program that loads in multiple external SWFs. There is a root to the project a main loader so to speak and there are externally loaded sub components. Each of these components inevitably shares classes with the main loader. You want to make it easy to identify which classes are shared so you know what to publish when you edit an ActionScript file (.as file). Your package organization needs to be inline with this philosophy. Many people try to organize package structure on a topical basis. Sometimes one will have a set of classes that are all scattered about many SWFs but that programmer organizes them under one package by topic. For example all these classes could thematically be considered classes that deal with navigation, this does not mean you group them under a single navigation folder. I suggest that except in the case of util classes, helper libraries and tool kits, files should be structured according to publish structure. This gets especially important when you build large projects with many SWFs. Say you change a file some where, how do you know what SWFs that touches? How do you know what to republish? An appropriate package structure will help you determine what to republish based on what classes you have edited. If your application gets big you don't want to have to republish the whole thing every time you want to test a change. Files that will be shared are ultimately singletons, common libraries (as3 libraries that rarely if ever change), utils, interfaces, constants, and events. Here is an example of such a design pattern as applied to package structure:

• com (folder)
  • yourUrl (folder)
    • loader (folder )LoaderClass.as
      : simple loader document class for loader.swf that loads in MainClass. It is important to keep the preloader simple and completely decoupled from the MainClass which is the beginning of your program. Note that there is no loader common folder because there is nothing shared between loader and main
• project name (project folder name)
  • main (folder)MainClass.as
    : this is main.swf it the main class which contains the starting functionality of your application. Lets assume that this class manages two SWFs that are loaded into Main.

• components (folder)
  • component1Common (folder) : This contains the glue between main.swf and component1.swf. Normally the component SWF gets loaded as an object and then casted to one of its implemented interfaces in Main.swf. The whole point of this folder structure is that you know that if something in component1Common changes then you know you have to republish main.swf and component1.swf.IComponent1.as
    : Component1MainImpl.as below implements this class

Component1Constants.as

: This allows you to share constants between main.swf and component1.swf

• component1 (folder) : This is the implementation folder it contains the all the classes that are known by component1.swf and not know by any other SWFs. The whole point of this is that you know if you change something in this folder then you only need to republish component1.swf.component1MainImpl.as
  : This is the document class for component1.swf it is named MainImpl because this is the main class for the SWFs and impl stands for implementation. This naming convention is a style choice, but it clearly denotes two things: one it is a document class and two that it is the implementation of IComponent1.swf.

AnotherClassThatIsOnlyUsedInComponent1MainImplOrAnyOfItsSubClasses.as

• component2 (folder) : Here we follow the same structure with component2.swfIComponent2.as

Component2Constants.as

• component2Common (folder)Component2MainImpl.as

AnotherClassThatIsOnlyUsedInComponent1MainImplOrAnyOfItsSubClasses.asNOTE: Now lets say that you have some classes that are used in both component1.swf and component2.swf These classes go under the components folder. so you know if any classes directly under component get edited that you need to republish both component1.swf and component2.swf. Likewise if you have classes that are shared across the entire application you would put them in "project name" and if you wanted main to have classes in common with loader then you would create a mainCommon directory. LinkedList.as

: these are all examples of classes that live under "project name" since they live under this directory we can infer that they are used in one or more sub components. You might be asking, "well what happens if LinkedList.as is in component1MainImpl.as not in component2MainImpl, but in Main.as. Should I not have a folder called MainAndComponent1Common?" You can embark down that road if you like but you are in for a wild ride. I just say except the redundancy and move ahead. If you start getting into complicated compile schemes and you want to avoid confusion you should automate your publish with a batch script that can tell what changed and what to publish. Unfortunately there are no easy answers to this problem in flash.
MemoryManager.as
JsonDecode.as
DoesSomething.asThis should help you keep your head strait on what you need to republish when you update a component of your application.