Software Components are typically business objects that have
predefined and reusable behaviors. Component-Based Development
is the idea of creating software applications from components.
Implementation detail is hidden in the interfaces, which isolate
and encapsulate a set of functionality. Interfaces are the
means by which components connect. An interface is a set of
named operations that can be invoked by clients. More importantly,
well-defined interfaces define the component's entry points,
and a component's accessibility is done only via its interface.
In a component-based approach, providers and clients communicate
via the specification of the interface, which becomes the
mediating middle that lets the two parties collaborate and
In summarizing, we have the following:
component is an independent, application-level software
unit that is developed for a specific purpose and not for
a specific application. Components are self-contained, pluggable
abstract data types. They are of large grained entities.
Component assembly (application development) is concerned
with high level domain experts rather than programmers.
Programmers will be responsible for component construction
and the fabrication of components for use would be accomplished
by component assemblers.
are accessed through well-defined interfaces. A component's
interface serve as the access points to its functionality.
These interfaces may be implemented by objects internal
to the component, if the component developer so desires.
But interfaces may be implemented by a non-OO language.
a single instance of a component exist per system. If there
are more than one client accessing the functionality being
provided by the component, different object references may
be distributed to those clients. An object reference is
a handle to an object in a component which implements an
comprised systems will typically feature components from
different vendors. Components will be interoperable by conformance
to industry standard interfaces
will be encapsulated and modular. Their internals may utilize
inheritance for implementation reasons. This fact will remain
as an implementation detail, not visible to the component
clients. Components can not be extended by inheritance.
It is worth considering the relationship existing between
components and objects. A component approach to software development
builds upon fundamental constructs of object-oriented paradigms.
Although the terms "component" and "object" are often used
interchangeably, a component is not an object. An object is
an instance of a class that gets created at runtime. A component
can be a class, but is usually a collection of classes and
interfaces. At runtime, a component becomes alive when its
classes get instantiated. Therefore, at runtime, a component
becomes a web of objects.
Their usage seems synonymous. While objects are well-suited
for component construction, a non-OO approach to component
construction is perfectly valid. The following explains how
objects differ from components.
are large-grained entities, e.g. a payroll module. Objects
are fine-grained entities, e.g. a Person.
are accessed via well-defined interfaces. Objects are also
accessed via interfaces. Thus the two are similar in this
respect, but not identical. Components interfaces are based
on industry standards, object interfaces are not. A component
with a CORBA IDL interface is easily accessible from any
language. An object implemented in C++ is not easily accessible
from another language. Components need not use OO approach
to implement their interfaces. The same is also true of
objects. The objects often act as wrappers to non-OO-code.
single component instances will exist per system whereas
multiple objects will exist per system. Components are more
akin to Object factories which also delegate functionality
to objects within the factory.
based systems will be made up of heterogeneous vendor components.
Seamless integration is possible as components will be built
to industry standard interfaces. Achieving the same with
objects tends to be more difficult as objects are built
to proprietary interfaces, thus can not be seamlessly integrate.
Such integration is possible if the object interfaces are
standard such as Java AWT.
will be runnable out of the box. Only Java objects on a
system running a JVM can boast of this property.
can be encapsulated and non-extendable. Objects will be
both encapsulated and extendible through inheritance. But
inheritance may be misused and hence this is being avoided
in components as component assemblers are experts in domain
knowledge not on OO techniques.
The aim of software components is to deliver better applications
to the market in a shorter time. This is easily achieved through
leveraging existing components. Thus the philosophy of component
assembly is re-use. The philosophy for component construction
remains the same.