Re: Design document on "deep vs shallow APIs"...

On Sunday 29 June 2003 18:02, Herman Bruyninckx wrote:
> I've put a very short document on-line that explains the concepts of
> Deep and Shallow APIs, and Multiple Dispatching:
>
>  <http://www.orocos.org/deep-shallow-api.html>
>
> (I think these concepts are useful for all discussions on the
> definition of APIs...)
>
> As ever, feedback is very welcome! Especially on this one, because I
> am not too sure about what I write in this document :-)

As I am co-responsible for the ideas of this document, I need to add that for 
basic, abstract interfaces, it is possible to provide a decoupled hierarchy, 
but as you want to extend functionality, more and more interconnection will 
be required and not only through composition of interfaces. Interfaces itself 
are the way to decouple objects, there is no need to decouple the interfaces 
themselves again ! They are meant to be the only, concentrated, 'coupling 
points' between objects. Another consequence of many interfaces is that it 
'looks' more like spaghetti than little interfaces, but that is not 
necesarily wrong. An example :

class CompositeInterface
{
	addA( InterfaceA* );
	addB( InterfaceB* );
	doStuff( InterfaceC* );
	connectThings( InterfaceD*, InterfaceE* );
	....
};
class InterfaceA
{
	request(InterfaceC*);
	notify(InterfaceF*);
};
class InterfaceB
{
	calculate(InterfaceC*, InterfaceA*, InterfaceE*);
};
 etc....

The advantage of the above is that operations are very strict defined : 
connectThings() connects a D and an E and will only use the operations 
defined in these interfaces. This allows safety in programming but fragility 
when interfaces change, and they will change because it was hard in the first 
place to find them, don't count on it that you got them right from the start. 

The point I actually wanted to make is that dividing functionality in small 
pieces means _more_ work on many more places than working in (moderate) 
monolithic blocks. In the end, I think the 'small' Interface paradigm  can be 
used on the component level and less on the object level. With the remark in 
mind that the component interface itself will not be that small anymore 
(since it needs to deliver practical functionality).

Peter

-- 
------------------------------------------------------------------------
Peter Soetens                                      http://www.orocos.org
Katholieke Universiteit Leuven
Division Production Engineering,                      tel. +32 16 322773
Machine Design and Automation                         fax. +32 16 322987
Celestijnenlaan 300B                   [email protected]
B-3001 Leuven Belgium                 http://www.mech.kuleuven.ac.be/pma
------------------------------------------------------------------------