Berin: I have read through your note a couple times, just to make sure that I find any corrections that are necessary. Your explanations help. Thank you.
The only corrections I found, though, are in my use of the word interface where it is actually called a Role or Work Interface. I will make that correction, and wait for any other corrections that need to be made, in case others find errors. Let me know if there is anything else below here that I missed. Pete Carapetyan Berin Loritsch wrote: > > > 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]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
