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.
Interesting read. Some comments, you are referring to inheritance as reusing code, and you are also mentioning one of the problems, that is “subclassing” a class to suit your specific need. Inheritance is mainly more about specifying an “IS-A” relationship between objects, not about reusing objects behavior. The more obvious problem is that you are strong coupling your objects together, like a chain with a weakest link. The introduction of Interfaces in Flash MX 2004 pro might be the start for developers thinking more and more about interface inheritance than about implementation inheritance.
About components, you basically described the workflow of many VB and Delphi developers and FormBased development. That is exactly what i mean in my posting “The future of Flash ( pt1. Runtime Model )” ( see last alinea ). Also EJB is coming close to a runtime component model, not to forget CORBA and COM(+). There is alot of similarities to Flash RIA development, and i wondered why the Flash Community didn’t pick this up. Again, Ted has been doing great stuff with PowerSDK, and his framework really should deserve some more attention.
About the implementation of Components and workflow in Flash MX 2004, there are some serious issues about deployment and development of SWC files, and i wouldn’t recommend them at all for using them as an equivalent of a .NET Component ( Assembly, DLL ) or an Java Enterprise Bean.
The way i look at it, it seems that classes encapsulate more often than not, a single piece of functionality. Components bring several of these individually functional pieces together to build something on a little more of a “macroscopic” level. However, even though the component is using several classes, each with different pieces of functionality, the component itself still has one overarching function to it. What do you think?
Can you elaborate on your comment “there are some serious issues about deployment and development of SWC files”? I would like to know specifically what you are referring to.
Yeah, I guess the best thing about components is the fact that they promote you not to mess with them. Interfaces are definitely a good addition and I’m looking forward to seing them applied in Flash Applications. There still is a long way to go, but I believe we are headed in that direction. It definitely is exciting
Nice entry btw on your blog Owen.
I like it Phil. That is for sure a big part of components. To add, I think another is distribution and versioning. If I purchase a component from a 3rd party, itÃ¢Â€Â™s not difficult to update it down the line if the 3rd party makes an update available. That is part of the theory behind components, at least for me.
Well said man,
Been waiting for an article like this to illustrate the gr00vyness of components.
Good read indeed.
I loved reading this great blog. Thanks.