Agile Enterprise Application Development with Flex

Introducing Application Domains

You’re packing for the snorkeling trip with your kid. Into your travel bag you put the two new pairs of goggles you bought just yesterday. Meanwhile, your small one found two old pairs in the garage and placed them in his backpack. You arrive to the beach with two sets of goggles. Which ones are you going to use?

• You are a perfectionist. You want the spotless snorkeling, and use the new goggles.

• You are a good father. You want your kid to feel that his preparation for the trip was important and use the old goggles.

• You are a pedant. You use the new goggles. Your kid should have consulted with you instead of bringing old ones.

Now, if we replace the travel bag with a parent application domain, your kid’s backpack with a child application domain, and start discussing class definitions instead of goggles, the only choice you are going to get is #3, or “delegate to your parent.”

Classes get loaded into application domains, which form a tree. By default, a module’s classes get loaded into the child domain (of the application or parental module). The child has access to all classes in the parental chain. This means that a module can create all the classes the application can (your kid can use your goggles).

On the contrary, the application does not get access to the classes carried by the module (you are not allowed to open your kid’s backpack), and the child can’t reload the class already known to the parent (your goggles are the only ones your kid gets to use). ...