Weblogs Forum - The Backside of an Interface

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Weblogs Forum
The Backside of an Interface

46 replies on 4 pages. Most recent reply: Mar 6, 2006 7:33 AM by piglet

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 46 replies on 4 pages [ 1 2 3 4 | » ]

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

The Backside of an Interface (View in Weblogs)

Posted: Feb 9, 2006 12:53 PM

Reply

Summary
A colleague of mine, Peter Grogono, brought to my attention recently the overlooked backside of interfaces.

Advertisement

The following quote was from a talk given by Peter Grogono, and surprised me something solid. Because I thought there wasn't anything I was fundamentally overlooking about software engineering :

Interfaces and calling out the back Another thing that all software engineers and many other kinds of engineers seem to agree about is the separation of interface and implementation. Of course, thats closely related to encapsulation. I hope we all agee that the data members of an object should be private. So the interface of the object is defined by the methods it provides. Right? Well, up to a point.
Electrical engineers work with boxes. What comes out of the box is the interface. Whats inside the box is the implementation. Heres a box. Is this its interface?
No, not quite. It has a back as well as a front, and heres the back. The interface consists of both the front, with the user controls, and the back, with all the wires going to the rest of the world.
How does this relate to objects? The public methods of an object are just the front view: the user controls. The interface consists of the public methods provided to users and the methods of other objects that the object calls. But in design we tend to ignore the back and worry about the front only. UML encourages this, by the way.

Grogono gives credit to Brian Shearing for this "calls-out-the-back" problem. Peter went into more depth in his talk, but this idea alone is something which rocks my world.

Cognitively I feel a Boa constrictor which just swallowed a goat. I am going to have to go away and digest it a bit. Maybe you care to tell me whether or not this is obvious, and if it is why don't more programming / specification languages address it. Or you can try to convince me why we shouldn't be considered about what dangles out the back of the boxes.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: The Backside of an Interface

Posted: Feb 9, 2006 1:58 PM

Reply

"No, not quite. It has a back as well as a front, and heres the back. The interface consists of both the front, with the user controls, and the back, with all the wires going to the rest of the world."

I think this is a flawed analogy. The wires don't just go out into the ether shocking random animals. They plug into the interfaces of other boxes.

Brian Slesinsky

Posts: 43
Nickname: skybrian
Registered: Sep, 2003

Re: The Backside of an Interface

Posted: Feb 9, 2006 2:00 PM

Reply

Yes, this is important and often overlooked. However, I think a better name would be the back interface of an object. An object usually has multiple interfaces and the front panel is only one of them.

Usually the back interface is important in the construction phase. When you install the box, you're plugging in all the wires on the back. Once it's installed, the users only care about the front panel.

You might be interested in the Inversion of Control paradigm that's popular in Javaland. The basic idea is that we can make object construction more flexible by exposing the wiring as parameters to the object's constructor, or alternately as setters.

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: The Backside of an Interface

Posted: Feb 9, 2006 2:25 PM

Reply

> "No, not quite. It has a back as well as a front, and
> heres the back. The interface consists of both the front,
> with the user controls, and the back, with all the wires
> going to the rest of the world."
>
> I think this is a flawed analogy. The wires don't just go
> out into the ether shocking random animals. They plug
> into the interfaces of other boxes.

I think the question is "which other boxes?". This is usually not clearly specified in code, documentation or specification. Besides for a few import or using clauses, which may or may not be meaningful.

Morel Xavier

Posts: 73
Nickname: masklinn
Registered: Sep, 2005

Re: The Backside of an Interface

Posted: Feb 9, 2006 2:39 PM

Reply

> I think this is a flawed analogy. The wires don't just go
> out into the ether shocking random animals. They plug
> into the interfaces of other boxes.
I think that's the point that Christopher (and his colleague) were trying to make: an object has a "front" interface from where it can be used by other objects, and a "back" interface from where it uses other objects (and uses the front interface of the aforementioned other objects).

In electrical schematics and such this is usually fairly well documented, you know where your internal/back wires go and how the back interface works, usually not so in computer engineering (best you can get are usually mere hints via imports, other than that you have to dwelve into the code to see what exactly is used and how it is used).

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: The Backside of an Interface

Posted: Feb 9, 2006 2:44 PM

Reply

> I think the question is "which other boxes?". This is
> usually not clearly specified in code, documentation or
> specification. Besides for a few import or using clauses,
> which may or may not be meaningful.

I don't know about that. An object with two distinct and public interfaces is called an adapter. It's also common to allow components to be set at runtime but in this case, the object isn't creating another interface, coupling itself to another type's interface. Then you have some wiring that is all done by hand.

This is exactly how wiring works, say, in my house. When I replace a lightswitch, there's no interface other than two wires which need to be twisted to the proper partner wires and wrapped up with electrical tape. The you have a lamp which has an interface (on-off switch) and is coupled to another interface (the wall outlet.) Then you have boxes with two interfaces say like a fuse-box or a transformer. My dishwasher and disposal connect directly to copper wire from the wall with screw-down connectors, while the stove has a plug. There's no one way to do it. The approach depends on what you are doing.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: The Backside of an Interface

Posted: Feb 9, 2006 2:51 PM

Reply

> In electrical schematics and such this is usually fairly
> well documented, you know where your internal/back wires
> go and how the back interface works, usually not so in
> computer engineering (best you can get are usually mere
> hints via imports, other than that you have to dwelve into
> the code to see what exactly is used and how it is used).

There's no reason that documentation couldn't tell you this level of detail. In a strongly typed language it's easy to automate this.

But I didn't get the idea that this was about documentation.

Andrew Cowan

Posts: 4
Nickname: methusaleh
Registered: Feb, 2003

Re: The Backside of an Interface

Posted: Feb 9, 2006 7:05 PM

Reply

This is a known and quite well understood principle of OO and dependency management. It is reflected in the Dependency Inversion Principle and is quite well covered here: http://www.objectmentor.com/mentoring/OOPrinciples

I recall reading an interesting article here on Artima that discusses differences between public and protected interfaces also.

The 'calls-out-the-back' problem sounds like a nice way of describing the issue.

Cleo Saulnier

Posts: 77
Nickname: vorlath
Registered: Dec, 2005

Re: The Backside of an Interface

Posted: Feb 9, 2006 8:50 PM

Reply

I've been trying to get this across (on some other site of mine) for quite some time now. I called them outgoing interfaces. This is the key to reusability and is the foundation of my new project. Codecs are known to use this methodology. They call them "filters" mostly. It's a better way to stream data because you can link multiple components together. And even if the parts don't fit, you can easily write a converter to mold the data so that it does fit. I believe it to be the missing link (pardon the pun) of OOP. However, I believe that functionality should not be inside an object, but inside these black boxes independant of the data they act on.

Not only this, but independant components (on a slightly larger scale), can make threading much easier as there's no coupling at all. Not only that, but pipelining increases runtime even more in multi-cores.

It can be a strange way to look at things though if you're used to OOP. Instead of the object deciding what it calls, it only published what it needs (resources required) and it's up to the larger encompasing object (or application) to link these objects together. Right now, we're just plugging switchboard into switchboard without regard to what they connect to.

I'm SO glad you brought this up. I was worried this would never get recognised.

Martin Odersky

Posts: 84
Nickname: modersky
Registered: Sep, 2003

Re: The Backside of an Interface

Posted: Feb 10, 2006 1:58 AM

Reply

I also think that the "back interface" of a class is an important, and often overlooked point. It's necessary for true component softeware that goes further than the monolithic API's we mostly have today. There's a paper about this in OOPSLA 2005. See:

http://lamp.epfl.ch/~odersky/papers/ScalableComponent.pdf

Yours

-- Martin

Angelo Hulshout

Posts: 4
Nickname: angeloh
Registered: Aug, 2005

Re: The Backside of an Interface

Posted: Feb 10, 2006 5:19 AM

Reply

Is this really about the 'backside of an interface' and not about the provided and required interfaces of an object or component? I've seen a good reference to the DIP come by already, and Clemens Szyperski already wrote about required interfaces in 1997 (Component Software - Beyond Object Oriented Programming).
If this is the case, I don't like the analogy made here, but I do agree that software designs and documentation (in any form, from full models, simple documents to code comments) pay far too little attention to the required interfaces.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: The Backside of an Interface

Posted: Feb 10, 2006 6:34 AM

Reply

> I've been trying to get this across (on some other site of
> mine) for quite some time now. I called them outgoing
> interfaces. This is the key to reusability and is the
> foundation of my new project. Codecs are known to use
> this methodology. They call them "filters" mostly. It's
> a better way to stream data because you can link multiple
> components together. And even if the parts don't fit, you
> can easily write a converter to mold the data so that it
> does fit. I believe it to be the missing link (pardon the
> pun) of OOP. However, I believe that functionality should
> not be inside an object, but inside these black boxes
> independant of the data they act on.

This sounds interesting, can you provide any references that give more detail and/or examples? Is there not a widely accepted name for this? If not maybe this needs to be described as a pattern and named.

You are not suggesting this as a general solution for all problsms, are you?

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: The Backside of an Interface

Posted: Feb 10, 2006 2:48 PM

Reply

Methods are the front of the panel, and delegates are the back of the panel. Delegates are connected to methods, thus forming a circuit.

The back of the panel also contains methods and the front also contains delegates.

Methods are the inputs, and delegates are the outputs.

Here is a my view posted in LtU about it. I have named that type of programming component-based:

http://lambda-the-ultimate.org/node/945#comment-9285

Gregor Zeitlinger

Posts: 108
Nickname: gregor
Registered: Aug, 2005

Re: The Backside of an Interface

Posted: Feb 10, 2006 3:20 PM

Reply

> Is there not a widely accepted name for this?
It reminds me of the Eclipse plug-in architecture. Eclipse plug-ins are those black boxes and are wired together in XML files.
Other names may be plug-ins (in a broader sense), or service provider interfaces (SPI).

Marcel van Kervinck

Posts: 1
Nickname: marcelk
Registered: Feb, 2006

Check out the Koala Component model

Posted: Feb 11, 2006 12:48 AM

Reply

You may be interested to check out the Koala Component model,
developed in Philips. Last time I heard about it they used it at
a large scale in their consumer electronics products.

In Koala, components need to specify both types of interfaces.
They are called 'provides' (front end) and 'requires' (backside).

Systems are composed by aggregating modules and resolving
both kinds of interfaces at compile time. The designer must
specify what components hook to what other components inside
the aggregate. Unresolved interfaces become interfaces of the
aggregate itself. A completed system has no unresolved interfaces.

A good starting point is http://www.extra.research.philips.com/SAE/koala/

Flat View: This topic has 46 replies on 4 pages [ 1 2 3 4 | » ]

Previous Topic

Next Topic

Sponsored Links

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use