Thursday, July 08, 2004

Classes, Objects, and Components

We all know about classes, and its features. We know how we design and develop methods and properties, and their respective access modifiers. Over the period of time, the definition of class gets mature and consistent across the programming languages to implement. The classes, at runtime, get instantiated into objects and behave according to their respective states.

When we instantiate a class, we get an object. An object represents a specific state, which includes the values of the properties, and also represents the inter-dependency with other objects. Classes provide a good degree of encapsulation to represent the abstractions of the real world entities. However, classes pose a few limitations while going for large application development. While classes offer the facility to provide contractually defined interfaces, it has little provision to offer language independent interfaces through which the it can be accessed. It also do not offer very good independent deployment scope.

Thus comes the conecept of component which satisfies everything that is there for a class, and something extra. This "extra" makes a component to be deployable independently, as well as offers composition by third parties. An application built using components are said to be more robust, more flexible, and reduces the development time. It is said to be robust since it implements the services of the real world entities rather than just the real world entities. It is said to be flexible since it offers the third party language neutral composition. While classes take the mathematical modelling of the approach to the software, components takes the engineering approach. Thus the component based architecture offers better time to implementation.

Like class, a component, when instantiated, creates an object. However, there is a little difference with the object created out of a component with the object created out of a class. Components need containers.