Preface

In the old days of ActionScript 2.0 a common practice was putting all the code into one frame on the timeline. When these developers made the transition to ActionScript 3.0 they would focus a lot on learning the new language syntax. What they really should have done was studying object oriented programming.

The problem

When ActionScript 3.0 emerged it contained a brand new syntax. It also proposed a transition from procedural programming towards object oriented programming. Surely ActionScript 2.0 was among some developers considered to be object oriented, but compared to ActionScript 3.0 it was a still a pseudo language.

This is where many of the former ActionScript 2.0 developers got left behind. Some of the developers learned the ActionScript 3.0 language syntax but never really learned object oriented programming. They would write ActionScript 3.0 code but in a procedural structure. They never really grasped the concept of classes, composition, inheritance, encapsulation and polymorphism.

This type of developer would create a single document class and write the entire application inside this class. I have seen document classes with a length of more than 2500 lines. Clearly, they got something wrong and could just as well continue writing procedural ActionScript 2.0 code on the timeline.

The solution

Composition is one of the easy OOP tools to learn. Hence the name, you “compose” your application of class instances, making encapsulation possible by defining a proper API of each class. Instead of writing the entire application in a single class you nest objects. A series of nested objects is referred to as the object creation chain (diagram 1).

Next we’ll take a look at object responsibility.

The Hollywood Principle

Since the object creation chain is ordered in a hierarchical structure it is natural to assume that top level classes have greater responsibility than classes placed lower in the hierarchy.
It’s just like the army: The top dog calls the shots while the cadet scrubs the floor.
Diagram 2 shows the responsibilities of a class tree build as a simplified MVC pattern (model view controller)

When invoking this principle, a low level menuItem object cannot call methods in the higher level menu object, since the menuItem object does not hold a reference to the men object. The same rule is applied up the chain.
An object should never know who has created it and must be totally decoupled from its creator.
Since objects do not hold a reference to its creator, it is not possible for child objects to call methods in their parent classes. And that’s exactly what we are aiming for.

This rule of thumb is called the Hollywood Principle. The basic rule is: “Don’t call us – we’ll call you”, meaning that parent objects can call child objects but child objects cannot call parent objects.

In case you need a higher level object to perform an action when an event occurs in a lower level object you should always dispatch an event. This way, the higher level object will decide whether the requested operation should be carried out or not. Lower level objects can request an operation in a higher level objects but never demand it.

Tight coupling versus lose coupling

This approach is a giant leap on the way towards loose coupling where objects do not depend on each other. In the opposite scenario called tight coupling objects are intertwined and strongly dependant on each other. In an application build with loose coupling, you can add or remove sections of your code without breaking surrounding functionality.

Conclusion

Using composition will definitely produce larger amounts of class files, which is highly desirable.
The aim is to encapsulate small pieces of functionality into many packages and classes.

By using composition and other core OOP techniques you are able to create a quick overview of your application by examining the class tree.