With the release of Flash MX 2004, IÂ’ve been giving a lot of thought to the importance of Components in application development. It seems like we keep moving more and more towards building applications around components. Now with the addition of Form based applications, and data components, components are even more important. I canÂ’t really imagine building a good application that uses forms without having everything (almost) as a component.

I’ve also been comparing Flash’s direction to other development platforms. If you take a look at .Net, components pretty much comprise most parts of an application. You never hear .Net developers discussing MVC. They just talk about using components. With that, I started reading a new book this week title “Programming .Net Components”. The book starts off with a chapter where the author discusses the benefits of Component-Oriented Application Development and why it is realistically better than OOP. It can be argued that Components themselves are just a collection of classes. The important thing is to step away from the technical part, and think more about what components really mean in an application.

To do that, I will try to mention some of the differences that I find for Flash in particular. One of the biggest problems with application development is maintenance; you can build applications very quickly if you never had to worry about maintaining an application. Now one of OOPÂ’s main goals is to improve maintenance, and it does. OOP allows us to model our application well, reuse code, and isolate certain objects from others. This in reality is not always the case though. Many times you end up sub-classing an existing class and or changing a class just to get it to do what you want. This in the book is called the white-box approach because you have to have knowledge of the inner working of the classes and rely on the inherited methods. On the other hand, with components you do not usually know the inner workings, but just use it (black-box approach). The only thing you care about it its interface and the rest is done for you. Usually components comprise a set of classes with a single unified interface. Also using components usually means we are forced to use composition over inheritance, and as we know from design patterns, that is usually better. A componentÂ’s interface and the component is very well architected and tested. With the new component architecture, components now have a pretty good set of guidelines on how they should be developed, and all UI components support certain methods/properties (setSize(), move(), enabled, etc). This makes our life easier because whatever component we pick up, we can get familiar with the component very quickly, and for component developers, a lot of the guesswork has been removed.

There are other things that also are benefits. Components, especially now with the addition of SWCÂ’s, are usually packaged up. This at first may seem like a pain or not really a benefit, but having components packaged as an SWCÂ’s will help in further promoting the usage of components. ItÂ’s not so easy anymore to just open up a component and change a line or two for your specific needs. If you need it to do something then you use itÂ’s API, if not then you will have to create a specialized version for your needs. What this does is help maintain the api of a component long-term. With the .Net platform, most developers donÂ’t know how to develop components themselves. What they do is just purchase components that fit their needs. If the datagrid that ships with MSÂ’s VS.NET does not meet their needs, they go out and buy one that does. This is good news for component developer and application developers. Component developers will actually have a real target audience now, and application developer will eventually have a larger pool of feature rich and well built components. I personally donÂ’t mind buying a component that does everything I need, and I believe a lot of people will feel the same way.

Components also help larger groups of developers work on a project. A project is much more successful and more easily managed if you split up the work according to components rather than classes. With components, you just provide the developer requirements of the api and the rest is handled by the developer. The developer can build the component, test it, and deploy it without having to worry much about the actual application it will end up being used in. If there is a bug in the component down the line, that developer can isolate that issue and provide an update to the component without affecting the rest of the application.

Components are easier to deploy than classes. Since everything is packaged up together, you can just distribute a new version as of the swc, and developers can update their project easily. Yes it is possible to do the same with classes, but with components this type of behavior is promoted and is simpler to achieve.

IÂ’ve tried to touch on some of the thoughts I have been having on the subject. There really is a lot more to this. I think the hardest thing is trying to distinguish what is a component and what is a class. I truly believe that components are and will become very important in Flash Applications. To me, everything is a component. With Flash MX 2004, Macromedia has made the job of component development much easier. Things that used to take time before, now take a few minutes once you get a good understanding of the new architecture. I donÂ’t believe everyone will need to learn the new component architecture, but it will definitely be a good asset to any application developer. Finally, maybe MVC is not that important (I was never completely satisfied with it myself). Instead having well architected components is.