Component
substitutability
- unit of independent deployment
- unit of third party composition
- no persistent state
Object
identity
- unit of instantiation
- (persistent) state
- encapsulation of state and behavior
slide: Definitions
[Szyperski97] proposes components as a suitable unit
of deployment instead,
and advocates a component-oriented approach
to deliver reusable `off-the-shelf' components
for a composing large applications.
Let us look at the definition of software component
given in [Szyperski97]:
A software component is a unit of composition
with contractually specified interfaces and
explicit context dependencies only.
A software component can be deployed independently
and is subject to composition by third parties.
This definition was the result of an ECOOP96
Workshop on Component-oriented Computing.
Notice that the definition itself contains
a reusability requirement, in mentioning
composition by third parties.
The requirements of explicit context dependencies,
the absence of inherent state and contractually specified
interfaces only strengthen this.
In contrast, an object is not a unit of deployment,
but a unit of instantiation.
Objects are not used in isolation.
Objects, do have state and identity.
Deploying an object or a collection of objects, moreover,
is often subject to (implicit) assumptions
concerning the interaction of objects.
Components as better objects
From the characterization above it might appear
that components are just better objects.
To some extent this is true, but there are some
important differences.
First of all, in practice, there is a difference
in granularity. Components are usually large grain,
such as a text editor or database component.
Objects, on the other hand, may be small grain,
such as dates or text fields.
Secondly, components are opaque, `binary units' of functionality,
interchangeable with units that deliver the same functionality.
Objects, in contrast, carry a state and may be regarded
as the living building blocks of an organic system.
[Szyperski97] mentions that there is a debate
whether inheritance is of relevance for component technology.
No doubt, inheritance, although somewhat overrated,
is an invaluable mechanism, both interface inheritance,
to define hie-rarchies of types, and
code reuse or implementation inheritance,
to allow for incremental development.
Reconsidering the definitions given,
I tend to think of the distinction between
components and objects as a distinction between
perspectives.
From a deployment perspective we need components.
From a developer's perspective we might prefer to speak
about objects.
Unfortunately, matters are not that easy.
But we need to take a closer look at the technology
to find out why.