commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ola Berg <>
Subject Re: The exegesis
Date Mon, 12 Aug 2002 22:27:28 GMT
>> Niclola wrote:
>> There is NO TECHNICAL NEED of having interfaces like these.

Stephen wrote:
>Actually thats half the point. 

Or to put it another way, there are _different_ needs for such interfaces.

Avaloners say that 
1) Avalon tried to keep their interfaces unrelated
2) Learned the hard way that the interfaces must be related (with a well defined contract)
to achieve their goal.

But what if our goal isn\'t the same as yours? As stated zillion of times, we are _not_ trying
to create Avalon2 in commons. We are on a different track. 

The notion of a Resetable fx is an object that can be brought back to a pristine state, via
a call to a reset() method. That _could_ be a part of a complete \"Recyclable\" contract in
any framework X. But also work in fx a test bed. In fact work in every context where \"bringing
back an object into pristine state\" is a meaningful operation.

Just as \"pristine state\" is a meaningful term in the language, useful in many contexts but
having the same meaning in all of them (without anyone but the object itself having to know
exactly what the pristine state is), Resetable is a meaningful interface in many contexts,
many of them which are not yet written. The proposed interfaces forms a kind of \"language\"
or lists of \"lexemes\" or \"words\": not sentences or full grammar like Avalon, but not just
tiny letters as java. They are situated somewhere in the middle.

Or compare it with the role abstraction in Avalon. In Avalon, the components role is defined
in relationship with the setting, just as \"Hamlet\" is defined in his castle in relationship
to the ghost of his father. This is the Avalon view, which is fine and well defined.

But for an author, there is a layer of abstraction beyond that. Yes, you write your play and
develop the specific characters and the setting accordingly. But there are in fact meta-roles
involved: common stereotypes that work in about the same way in different settings: the trickster,
the old wise man, the closed room etc. 

After watching and writing hundreds of plays, one can see a recurring theme of these stereotypes.
As an author you use them as building blocks. You benefit from them. This is at the patterns
level, in OO design terms.

Now, after writing hundreds of programs, one can see recurring patterns of such meta roles.
Some objects should be resetable. Looking back, one can see that \"Hey, if all of the objects
that can reset() themselves (a pattern) had implemented the Resetable interface from the beginning,
I could write a general pool that reuses them, without having to refactor them at all!\".

Hence the idea that _some_ of these patterns can and should be formalized into concrete interfaces.
Or \"mechanisms\" as I prefer to call it, the interfaces supports one \"mechanism\" each,
like the mechanism of bringing itself back to pristine state, regardless of the surrounding
framework. Or call it \"mini contract\" or \"clauses - the building blocks that contracts
are made of\".

As for the \"you are trying to define interfaces before the implementation\" simply isn\'t
true. All proposed interfaces aids the mechanisms, and the mechanisms has been written before.

Not all patterns benefit from general concrete implementations. Not all clauses in a contract
stands alone. But some do, and it is worthwile to capture them and formalize them.


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message