Simon Wacker

An Inversion of Control container is an infrastructural backbone for applications by providing services like lifecycle management, lookup, configuration and dependency resolution.

Lifecycle management: The lifecycle of application objects is managed by the container. The container is able to create new objects, to populate them (applying property values), to invoke initialization and destruction callbacks.

Lookup: References to application objects can be obtained through the container. A container is so to speak a factory.

Configuration: Application objects can be configured in a consistent way (without needing recompilation); for example with an XML dialect.

Dependency resolution: The container should not only configure application objects with simple types, but also manage relationships between them.

While application objects should be able to take advantage of these services, they should NOT depend on the container. This can be achieved by Inversion of Control (and Dependency Injection). Inversion of Control containers are thus also called non-invasive containers.

IoC containers do not impose invasive dependencies on your code, but it is advisable to follow some good coding practices.

* Code to interfaces to maximize pluggability.
* Each application object should have a clear set of responsibilities.
* Favor the Strategy design pattern over inheritance.
* Do not write code to do anything that the container can do.
* Use method prefixes in a consistent manner (Mutator Methods: Naming)

If you follow the preceding recommendations, you can also easily unit test your code and practice test-driven development.

In the next article we are going to take a look at the As2lib IoC container for Flash and its simple XML dialect.

I was shocked when I read in a forum on Flash from a developer I really admire that he has never used interfaces as type definitions. He even asked if that really works. I just thought: “Huh! What’s going on?” Thus here a few thinks I learned about interfaces:

The Key Sentence:
Program to interfaces rather concrete implementations.

That’s the sentence you should always keep at the back of your mind while programming. Following this golden rule offers the following advantages:

1. Loose coupling between objects which promotes flexibility. You are not bound to concrete implementations. Thus you can change them easily when you have to without affecting calling code.
2. You can write simple stub implementations to ease the testing of classes. It also enables teams to work in parallel after they have agreed on interfaces.

Interfaces in Flash are sadly not that mature yet. There are a few problems related to working with them in practice. Martin and me came across them during the early days of the as2lib. He has summed them up in two posts on the as2lib blog: Interface Mistakes by Macromedia and :Object is Evil. But even with this limitations you should nevertheless work with interfaces because the advantages much outweigh the problems of them in Flash.
Read on to see interfaces in action.
(more…)

I know the term UML (Unified Modeling Language) covers a very big spectrum. It’s a topic everyone should know at least the basics about.
Well, and because of that I’m presently reading the book ‘The Unified Modeling Language User Guide’ from Grady Booch, James Rumbaugh and Ivar Jacobson. I really recommend you to read this book too if you are interested in Object Oriented Design/Concepts or just want to learn UML.
The possibilites the UML offers to model well designed systems is astronomical. While reading a new dream got born: a programming language which provides clean semantics to realize all these concepts in the real world.
And up to now I’m only on page 200. I wonder what comes next.
In my opinion before we invent a even better way to program then OOP we should try to imporve OOP till it becomes perfect. We shouldn’t always look out for new things. We should improve the old ones.
As you can see at the OOP example it lives since more than 40 years (I’m not really sure about that) and there isn’t a programming language that supports all concepts you could realize via OOP. It should be our task to build such a language. So that in the near futur it isn’t a dream anymore to build a system based on the UML with all the ideas and concepts it offers.

I’m just reading this book. It’s fasciniting. The ideas behind the patterns are really amazing. I can’t wait to implement a few in some of my new projects. I highly recommend to buy this book. You change the way you look at code. It has a similar effect to me like “Refactoring” from Martin Fowler. So buy it and I guarantee you you will love it.