[Home] [Next]
[Prev]
The ECO Paradigm
ECO vs Object-Oriented
ECO (Extender and Class Oriented) paradigm is an extension of the usual
object-oriented paradigm. This means that all concepts known in object-orientation
have the same meaning in ECO. Plus, ECO add its own concepts.
New Concepts
Extenders
The extender is the main concept introduced by ECO. Extenders
are classes that have the following additional features:
- An instance of an extender (we call it an extension object)
is created over a support object. It must
be created after the support object and it must be destroyed
before the support object. Thus, we can talk about current extensions
of a given support.
- When an event occurs, then the support object can notify it to its
current extensions. The notification is done by using E-methods.
E-methods give to the extension objects the following two capabilities:
- to change their state when the state of the support changes.
- to add constraints to the changes of the state of the support
(E-methods can throw exceptions).
- Given a class C and extender E for it, it is possible for a single
instance of C to be support for more than one instance of E.
The figure shows the graphical notation used for extenders (note the
"E" in the triangle).
Extenders are good to solve state
extension and multiple “decoration”problems.
This concept can solve also the promotion efficency
problem because new information is added without create another instance
of the support.
E-Methods
E-methods must be declared in a class and their semantics is
defined in the extenders of that class. E-methods are only called
in the ordinary (non E-) methods of the extended class.
The call of an E-method provokes the execution of its semantic definitions
for each current extension object. Those executions have to be considered
as (virtually) parallel. This is possible because each semantic definition
of E-methods can modify only the status of the extension object, which
it is called for.
Of course, the interaction is sequential on a sequential machine. The
figure shows what happens when an E-method Check_ f ( ) is called. X is
the support of the extension objects Y1, Y2,...,Yn. The choice of E-methods
is a key part of the design because they represent the communication
protocol between an object and all its extenders. Design patterns can help
the designer.
Dynamic Inheritance
![](dynnot.gif)
Extenders are useful to describe objects adding
information to another object, but there are situations where they are
not convenient. If the added information can be computed from the state
of the support, the possibility of having more than one extension has no
meaning. In this case extension objects represent a kind of dynamic inheritance,
that is just one instance for each extender (and for a given support) has
meaning. The programmer can access the dynamically added part through the
support.
The graphical notation for dynamic inheritance is shown in figure (note
the "D" in the triangle).
Dynamic inheritance is useful for solving the crossed
classes problem, because using this technique an object can be member
of more than one class: this set of classes is its ECO type.
This value can change dynamically during the life of the object.
This concept can solve also the promotion efficency
problem because the underlying mechanism is the same as for extenders and
no copy of the support is needed.
Trailer
An object can contain other objects; that is, it manages those objects
exclusively. The extender performs a state extension extending those objects.
The figure shows a typical case. Each object belonging to Graph
contains a set of objects belonging to Vertex. Labelling
is an extender of Graph. Each Labelling contains a set of
VertexLabel. VertexLabel is an extender of Vertex.
The design introduces another constraint: a VertexLabel should be
identified by a pair
<Labelling, Vertex>
Each Labelling can attach just one label to each Vertex.
|
![](trlr_cl.gif) |
![](trlr_o.gif) |
The object diagram in the figure shows a run-time situation. The graph
G contains two vertices V1 and V2, we call them tows.
G is support of two labellings L1 and L2 and we call
them owners. The objects contained in L1 and L2 are
called trailers. A tow may have any number of trailers, but each
owner can access only those it contains.
|
The described situation arises many times in the design. If a class
contains other objects, almost every extender of it must manage trailers.
[Home] [Next]
[Prev]