> From: Pete Carapetyan [mailto:[EMAIL PROTECTED]]
>
> Separation of Interface/Implementation
>
After looking at your visuals, I do have some comments.
Separation of Interface and Implementation is at the core of
component oriented programming. You cannot have one without
the other. Unfortunately, some people feel it necessary to
confuse the issue by calling every standard API a component.
The Avalon terminology for the interface is the "role". The
role is the work interface, or the interface that you as a
user of the component interact with. The reason we call it
a role is to help when decomposing the system down into
different components.
One thing that you have to understand about component
programming is that implementation != interface. Java has
a keyword "interface" that we use to define our interfaces.
In work interfaces (or roles), we define the minimum set
of contracts that any implementor of the role must satisfy.
The ever popular ObjectStore example will have a base interface:
interface ObjectStore
{
void store(String key, Object store);
Object retrieve(String key);
Object remove(String key);
}
The minimum contracts this interface satisfies is that an
object is stored with a client specified String key. The
client can then either retrieve the object or remove it
using the same key. When the client calls the "retrieve"
method, the object remains in the Store, but when it calls
the "remove" method the object is removed from the store.
Notice that there is no meantion of wether or not the
ObjectStore is persistent (i.e. data remains across JVM
invocations).
In order to satisfy that _guarantee_, we extend the interface
like this:
interface PersistentObjectStore extends Store
{}
They both have the same basic guarantees, but the new
interface has the added contract that it must be persistent.
Notice in neither of these cases, there is no mention of
_where_ the components are stored. That is not important to
the client. Configuring the components is a different
concern.
When you define interfaces, you must think of the *function*
of the component. Sometimes it is better to have many smaller
special purpose components than one large component that must
change its interface each time a new contract is placed on it.
To clarify the roles of the patterns used, look below:
Separation of Interface and Implementation:
basic definition of a component.
Separation of Concerns:
keep the management, use, and configuration interfaces separate.
This simplifies the client's view of the component.
Inversion of Control:
how containers and components work together.
If you need any more clarifications let me know.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
