Beyond Object-Oriented Programming
Resumed by Et.
I. What a component is and is not
In contrast with the notions of instantiation, identity and encapsulation
of state and behaviour, which lead to the notion of object, the characteristic
properties of components are:
Obviously, a component is likely to come to life through objects and therefore
would normally consist of one or more classes or immutable prototype objects.
However, there is no need for a component to contain classes only, or even
to contain classes at all. Instead a component could be realized by traditional
procedures or functional programming.
A component is an unit of independent deployment. This implicates that
components must encapsulate all its constituent features.
A component ia a unit of third party composition. Therefore components
must be self-contained and be provided with good specifications of what
it requires at provides.
A component has no persistent state: in any given process, there
will be at most one copy of a particular component.
The superclasses of a class do not necessarily need to reside in the
same component. The inheritance relation between them crosses component
boundaries. Is this a 'good' thing or not?
A Definition: software component
" A software component is an unit of composition with contractually
specified interfaces and explicit context dependencies only. An software
component can be deployed independently and is subject to composition by
Specification of interfaces should be market-oriented...Standardization!
Context dependencies are component world (CORBA, DCOM, Sun's Java)
Components, interfaces, and re-entrance
II. Components and interfaces
The problem with object interfaces
One distinguishes between direct interfaces (procedural interfaces or static
interfaces) and indirect interfaces (object interfaces, made available
by the component). The problem with the latter one is that the dynamic
binding concept, central in OOP., makes the resulting configuration of
a component system harder to control. Dynamic binding can lead to the involvement
of a third party, of which both client of the component and the interface-introducing
component may be unaware.
In a versioned systems especially (evolving interfaces, but also different
flavors of implementation), care must be taken to avoid coupling
of parties that are of incompatible versions. Unlike for direct systems
like procedural libraries, indirect coupling implies that version checks
must occur in every place where an object reference crosses component boundaries.
Exisitng solutions for this problem are is that each interface, once published
is frozen and never changed again. Too limited, if you ask me.
This versioning problem is of non-functional kind. A meta-architecture
approach , an AOP or a compositon filter approach can solve this problem
more profoundly.. Reflective component-based systems are the future!
The contract of an interface
A contract of an interface states what the client needs to do to use the
interface, and what the provider has to implement to meet the services
promised by the interface.
For example, on the level of the individual operation of an interface,
the two sides of contract can be captured by specifying invariants and
pre- and postcondition for the operation.
Contracts are used to control the evolution of software implementation:
Revised implementations must respect the contract.
The contractual specification not only consists of functional aspects
but may also specify non-functional requirements, concerning the implementation
strategy. E.g., a meta-program may monitor and control the so called service-level
of a component.
Contracts must be able to be specified in a disciplined manner, without
sacrificing the flexibility. To minimize risks, a contract needs to maintain
a balance between being precise and not being too restrictive.
Contracts must be platform-independent, for example execution time
constraints must be expressed in terms of time complexity instead of seconds.
What belongs to a contract?
Safety can be expressed using invariants
Progress conditions: the concept that something garantueed by a precondition
will lead to something guarantueed by a postcondition can be generalized.
Non-functional requirements, e.g. resource consuption, performance
Time and space requirements: the specification of time and space complexity
bounds in a contract could significantly add to the practical value of
that contract. To fill the gap with platform-specific bounds, a contract
should come with additional information required to determine absolute
III. Callbacks and contracts
Callbacks lead to exposing intermediate state of the component to
clients, while executing an encapsulating operation on behalve of
some client. It's important that this observable state remains valid as
long as any callbacks are active.
If not care taken, callbacks may easily lead to broken contracts. As
a callback's role is all about state and state change, most non-empty callbacks
observe or change more component state. If no appropriate action taken,
broken contracts occur, when the update of intermediate state resulting
from executing the callback may leave the state resulting from the execution
of the encapsulating operation invalid, i.e. in conflict with its
post-condition. An other related problem is so called indirect recursion
across abstractions caused by callbacks,
What is needed is a contract between component and callback implementations.
What needs to be captured is the condition when a notified observer is
(not) allowed to change the notifying observed object (i.e. calling state-updating
operations). It is however difficult to capture such a restriction
using a strictly local contract based on pre- and postcondtions:
An elegant middle ground is using callbacks with state test functions.
These tell wether or not a particular operation is currently available,
without revealing too much of the library's internal state. (Cfr the Correlate
abstract state machine approach for imposing synchronisation constraints).
A prominent example of test functions is the getInCheck() of the Java Security
The problem is that such a restriction is of transitive nature. A callback
may invoke any other operation that internally, for whatever reason, uses
the service of the component that orignally notified. As a consequence,
checking the restriction is a very dynamic and global process.
Asynchronously observable state, such as state observable by means of callbacks,
allows contracts based on pre- and postconditions to fit less well:
Asynchrony is more naturally dealt with by approaches developed to handle
concurrency, like process models Unfortunately the resulting contracts
are far less manageable.
IV. From callbacks to webs of interacting objects
One of the main prowerful aspects but also problems of object orientation,
is that object references introduce linkage across arbitrary abstraction
domains. This means that every method invocation is potentially an up-call,
every method pontentially a callback!
The flow of control against the layers of abstraction clearly may expose
inconsistensies to arbitrary other objects. The real problem is observation
of an object undergoing a state transition, with inconsistent intermediate
states becoming visible. As objects encapsulate state, such observation
is limited to what the object reveals. In other words, inconsistencies
can only be observed by entering an object's method.
The situation is most intricate when considering object re-entrance. If,
while in progress and before reaching consistency again, the intermediate
state is observed - by means of re-entrance - maintaining correctness becomes
It's difficult to maintain invariants in the face of self-recursion
or cyclic-dependencies. One way to address these re-entrance problems is
to weaken invariants conditionally and make the conditions available to
clients through test functions.
A significant number of design and implementation errors -often hard
to find and correct - go back to unexpected recursive re-entrance of objects.
Re-entrance in component systems
Recursion and re-entrance become an even more pressing problem when crossing
the boundaries of components. Problems due to unexpected object re-entrance
may be only solved when stepping back and inspecting the overall situation.
With components, this can be impossible to do as a component system, does
not have a final form. This demands that each component is independently
verifiable based on the contractual specification of the interfaces it
requires and those it provides.
Self-standing contractually specified interfaces decouple client and providers.
It's legal to substitute a client or provider for another if
the contracts with the cooperating entities remain unbroken.
However, a client may establish more than is required by the precondition
or expect less than is guaranteed by the postcondition. Likewise a provider
may require less than is guaranteed by the precondition or establish more
that is required by the postcondition.
established by client => guaranteed by precondition => required by provider
estbalished by provider => guaranteed by postcondition => expected by client
It would be higly desirable to have a compiler or other autmatic tool check
clients and providers against the contract and reject incorrect ones. Szyperski
states here that compile-time checking better is than load-time checking,
and load-time checking better than runtime-checking. This is however not
true for component-systems, because it's impossible to do so.
Mission-critical systems: some systems must provide 24h , 7 days
per week full-service. Extending such systems with adding/replacing new
components must be done dynamically, without stopping the system.
Source code of third partie components is not available
A lot of research needs to be done in this area...
VII. Type checking
The most prominent example of compile time checks is type checking, fully
eliminating memory errors.
In programming languages each interface has a certain type. A type
can be seen as a simplified contractt:
Interfaces which extend a certain base interface are said to be a subtype
of the base interface's type.
preconditions are specified by the types of the input parameters.
postcondtion are specified by the types of the output parameters and return
An object implementing one type (i.e. provider) can be used in a context
expecting another type, when it's a subtype and:
guaranteed by precondition (input parameter types) => required by provider
guarantueed by postcondition (output parameter types, return types) <=
established by provider (subtypes): covariance
VIII. Types, interfaces and components
In component systems, a self-standing interface has to be fully and explicitly
typed to benefit from typechecking.
Structural subtyping leads to partial contracts. A named type refers
to the full contract. Components must have a name.
Components may support multiple interfaces: it is sometimes necessary to
specifiy a required set of interfaces and then accept any component that
provides at least these required interfaces. Such interface sets are sometimes
called categories. I think names are as important as in the previous
IX. The paradigm of independent extensibility
The principal function of component orientations is to support independent
extensibility. A system is independently extensible if it is extensible
and if independently developed extensions can be combined.
However isolation comes at a price, and frequent crossing of protection
domain boundaries can severly affect performance, safety and robustness.
One way to solve this problem is to choose carefully the granularity
of components - if most interactions stay within a component boundaries,
the cost incurred when crossing component boundaries may be tolerable.
In the end, the design of componenent systems must strive between a
balance between flexibility on the one hand and performance, safety, robustness
on the other.
X. Safety by construction: viability of components
Besides hardware protection and compile-time type checking, additional
measures are needed:
A component has to specify explicitly which services it needs to access.
Example: the import Java statement.
It should be impossible for a component to retrieve references to other
components which it has not been granted access to.
For component systems, where meta-interfaces exist, these need to be explicitly
restricted such that these services do not break module safety. Indeed
a system may offer two metaprogramming interfaces: one that is module safe
and open for general use and another that is module unsafe and restricted
to trusted components, i.e. the core of the system. Example is the
BlackBox Component Framework (used with Component Pascal).
XI. Component frameworks
Dimensions of independent extensibility
Independently extensible systems require a clear statement of what can
be extended (forcing specialization would endanger the interoperability
of independent extensions). Each particular feature of an independently
extensible system that is open for seperate extension is called a dimension
of (independent) extensibility.
The theoretical ideal would be to form orthogonal dimensions of independent
extensibility that together form an extension space that is complete with
respect to extensibility requirements.
A component framework must provide an infrastructure which lays an common
ground for independent extensions to interoperate. Interfaces introduced
to allow the interoperation between independently extended abstractions
are sometimes called bottleneck interfaces.
Object versus class composition or how to
There are three cardinal facets of inheritance:
How to get classes right (correct) and robust (tolerate evolution and versioning)
led to the formultation of the fragile base class problem
implementation inheritance (the 'how to avoid inheritance' promise refers
solely implementation inheritance.)
subtyping or interface inheritance
the promise of substitutability
XII. The fragile base class problem
syntactic fragile base class problem: is about binary compatibility
of compiled classes with new binary releases of superclasses. The idea
is that a class should not need recompilation, just because purely syntactic
changes to its superclasses'interfaces have occured. For example, methods
may move up in the class hierarchy. However as long as they reamin on the
inheritance path, a subclass should not care. By initializing method dispatch
tables at load time, the above example syntactic FBC can be solved.
semantic fragile base class problem: How can a subclass remain valid
in the presence of different versions and evolution of the implementation
of its superclasses. The problem is very similar as the problem of callbacks
and re-entrance but now between base - and subclasses. Several approaches
to disciplined inheritance are described in the literature: specialization
interfaces, reuse contracts
XIII. From class to object composition
The idea is instead of relying on a callback to the superclass, forwarding
a message to an inner object. An outer object does not reimplement
the functionality of the inner object when it forwrds messages. Hence it
reuses the implementation of the inner object. If the implementation of
the inner object is changed, then this change will 'spread' to the outer
object. In this way the same advantages as implementation inheritance
are achieved, but without the risk of re-entrant message sequence explodes.
An other advantage is that dynamic composition is enabled with object composititon.
The difference with implementation inheritance is called the 'possession
of a common self'. There is no common self to a composition of objects.
This means however that when recursion across multiple objects is achieved,
it needs to be designed in, whereas in the case of implemenatation
inheritance it can be patched in. This is however sometimes called
planned versus unplanned reuse.
XIV. Forwarding versus delegation
Delegation = making object compositon as problematic as implementation
A recent focus of research has been the disciplined use of delegation.
As delegation can be used to form a common self across webs of objects,
one could term such webs themselves as objects of a higher order. such
'objects' are often called split or fragmented objects.
Aspects of scale and granularity
This relates to the problems posed at IX.
Various criteria are:
Units of abstraction
Units of accounting
Units of analysis
Units of compilation
Units of delivery
Units of dispute
Units of extension
Units of fault containment
Units of instantiation
Units of loading
Units of locality
Units of maintenance
Units of system management
Reuse: Patterns, frameworks, architectures
Independenty extensibility clearly relates to effective design reuse.
In traditional integrated software design, design experience is probably
the single most value in the basket of reuse ideas. Great designers are
needed. However, the architecture of component-based systems is significantly
more demanding than that of traditional monolithic integrated solutions.
In the context of component software, full comprehension of established
design reuse techniques is most important.
Design reuse can be understood as the attempt to share certain aspects
of an approach across various projects. The following list names some of
the established reuse techniques and for which sharing level they are beste
Sharing consistency: programming languages
Sharing concrete solutions fragments: libraries
Sharing individual contracts: interfaces
Sharing individual interaction architectures: patterns (see Coplien and
Schmidt, 1995; Vlissides et al., 1996)
Sharing architectures: frameworks
B. STATE OF THE ART
The various approaches differ in to what an interface connects to. Those
based on traditional object models define a one-one relation between interfaces
and objects. (CORBA). Other approaches associate many interfaces with a
single object(Java) or many interfaces with many objects in a componeny
The OMG way: CORBA and OMA
The Microsoft way: DCOM, OLE and ActiveX
A COM component may for example provide three different interfaces and
may use tow different objects to implement these. What is important, is
that there is no single object identity that ever leaves the component
and represents the entire COM object.
Two important questions are:
Reference counting is done for the COM object in its entirety or separately
for each of its interface nodes.
How does a client learn about other interfaces? by calling the QueryInterface
operation with an GUID interface identifier (IID), uniquely identifying
the requested interface as an argument
How does a client compare the identity of COM objects? By a special interface,
I. COM object reuse
No implementation inheritance. Support for reuse is provided by
Containment: inner - outer object relation
Aggregation: an inner object's interface is handed out directly to the
inner object, saving the cost of forwarding.
II. Interfaces and polymorphism
The true nature of polymorpism has nothing to do with interface inheritance,
but is the support of sets of interfaces by COM objects. The type
of a COM object is the set of interface identifiers of the interfaces it
supports. A subtype is a superset of interfaces.
COM defines categories to represent sets of interface indentifiers.
Categories function as contracts. A caegory specifies not only wghich interfaces
must at least be supported, but also which methods in these interfaces
must at least be implemented. This sucks the idea of contracts.
Problem: who maintains the list of categories?