The Artima Developer Community
Sponsored Link

Weblogs Forum
The Backside of an Interface

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

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 46 replies on 4 pages [ « | 1 2 3 4 | » ]
Max Lybbert

Posts: 314
Nickname: mlybbert
Registered: Apr, 2005

Re: just nod and say "yes" Posted: Feb 13, 2006 6:39 PM
Reply to this message Reply
Advertisement
/* [me]: It does. But that's not the point. Taking out the "final" part also makes the same statement. The issue is that this is a detail many people overlook.

[James Watson] I don't get your point. If the constructor requires an instance of the 'back interface' then how is it easily overlooked?
*/

It's easily overlooked by the programmer, not the language. Programming is always a human activity. A followup post on this proposes a language solution. I'm not commenting on that one yet. My understanding of this post is the detail is overlooked by programmers, who then have debugging issues when they look at other possible causes.

Jeff Ratcliff

Posts: 242
Nickname: jr1
Registered: Feb, 2006

Re: Re; the whole electrical comparison Posted: Feb 13, 2006 6:40 PM
Reply to this message Reply
"The speaker outputs is not analagous to the backside of an interface, because it has nothing to do with the microphone, it is part of the amplifier.

A better analogy is a pre-amplifier, which has an input, nobs and buttons (front-side) and an output (back-side)."

I don't see any difference. My microphone doesn't depend on the outputs or the knobs, just on the relevent input interface.

Max Lybbert

Posts: 314
Nickname: mlybbert
Registered: Apr, 2005

Re: Re; the whole electrical comparison Posted: Feb 13, 2006 6:50 PM
Reply to this message Reply
/* If I were designing a microphone to be compatible with a particular amplifier, I would concern myself only with the electrical characteristics of the microphone jack (interface).
*/

This is actually very common in computers. Try plugging a USB keyboard into a PS/2 slot without an adaptor. Or a firewire device into a SCSI connector. Many times the electrical characteristics of hardware are such that companies engineer wierd ports and connectors specifically to prevent you from plugging them in to the wrong slots.

I know you're up to speed on interfaces. The point cdiggins has brought up is that the microphone has *two* interfaces, although most people using the mike will only deal with the front side -- big foam ball and the "on" switch. But somebody has to make sure the jack is the right size, with the right output characteristics -- the back side.

I know, this doesn't sound like much. But how many programmers spend all day fiddling that on switch saying "I know this class should work, I'm fiddling the switch right" when the jack is not plugged in?

Jeff Ratcliff

Posts: 242
Nickname: jr1
Registered: Feb, 2006

Re: Re; the whole electrical comparison Posted: Feb 13, 2006 8:08 PM
Reply to this message Reply
The microphone is the user of the interface in this scenario, not the object with the interface. If you want to talk about the microphone as the object instead of the pre-amp fine, but let's keep the roles constant while we examine the problem.

If you want to talk about the microphone as the object and the human user as the "user" of the interface, it's exactly the same. The user needs to follow the requirements of the switch interface, the plug interface, and the accoustic interface. The parts inside the microphone are hidden from the user and don't affect the operation.

Max Lybbert

Posts: 314
Nickname: mlybbert
Registered: Apr, 2005

Re: Re; the whole electrical comparison Posted: Feb 13, 2006 8:30 PM
Reply to this message Reply
/* The microphone is the user of the interface in this scenario, not the object with the interface. If you want to talk about the microphone as the object instead of the pre-amp fine, but let's keep the roles constant while we examine the problem.
*/

Sorry, I hadn't been keeping up.

In the example of an amp's microphone interface, you are correct that there just isn't any way for the mike to trample on something inside the amp (aside from power surges). Even so, that doesn't prove that every hardware device effectively insulates its users from hidden dependencies. It *does* show that careful design can reduce the hidden dependencies.

My understanding of the original post isn't so much that there is a special kind of backside interface, but that many programmers overlook interfaces that an object depends on, or that manipulate an object behind the scenes. Since this can lead to hard-to-find problems, it's an obstacle to correct programs. My understanding of the follow-up post is that design by contract can watch out for the internal state of the object so that the programmer will catch these "hidden" calls.

Often programming correctness is based on "let's assume we start with a valid object, if all calls to the object leave it in a valid state, we know that the object will always be in a valid state." Great, and 100% true. Now go about proving *all* calls will leave the object in a valid state. And while you're at it, try to remember that not every interface to an object will look like a method, operator, or function call.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: just nod and say "yes" Posted: Feb 14, 2006 9:20 AM
Reply to this message Reply
> /* [me]: It does. But that's not the point. Taking out
> the "final" part also makes the same statement. The issue
> is that this is a detail many people overlook.
>
> [James Watson] I don't get your point. If the constructor
> requires an instance of the 'back interface' then how is
> it easily overlooked?
> */
>
> It's easily overlooked by the programmer, not the
> language. Programming is always a human activity. A
> followup post on this proposes a language solution. I'm
> not commenting on that one yet. My understanding of this
> post is the detail is overlooked by programmers, who then
> have debugging issues when they look at other possible
> causes.

i think we are interpreting the post differently. I thought the point was that when I get a class from apache, let say, and start using it, what it uses internally is hidden from me until I get some error about not being able to find X or Y. I see this as a programmer problem, not a language problem. Sometimes you want this, i.e. you don't need to know that I use a HashMap internally but you problably do need to know if I use a class that escapes the member scope. Developers can do this with comments and with methods and constructors. Mr. Diggins implied that languages don't support this but I disagree.

There's another sub-discussion here about plug-in type architecture which I see as specific problem realm that also has a solution in current languages.

Max Lybbert

Posts: 314
Nickname: mlybbert
Registered: Apr, 2005

well, I've been wrong before, ... Posted: Feb 14, 2006 12:38 PM
Reply to this message Reply
/* i think we are interpreting the post differently. I thought the point was that when I get a class from apache, let say, and start using it, what it uses internally is hidden from me until I get some error about not being able to find X or Y.
*/

That is a serious issue. I may be wrong about what the original point was about. I do know I've run into the Apache problem while trying to build Subversion, which uses the Apache Portable Runtime.

Vladimir Nesov

Posts: 27
Nickname: robotact
Registered: Aug, 2005

Re: well, I've been wrong before, ... Posted: Feb 18, 2006 8:39 AM
Reply to this message Reply
It's more about library dependencies then. It shouldn't matter what implementation classes are used in implementation of other classes while they all remain in single library. And it also shouldn't matter which interfaces of other libraries those implementations use. It only matters which libraries should be there to use library in question.
There is also 'complete-incomplete' library problem, but there is no general solution really, since even if some incomplete library provide necessary interfaces you can't say if specification fits with what you expect.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: The Backside of an Interface Posted: Feb 20, 2006 7:01 AM
Reply to this message Reply
> Its a little naive to think that a software component
> would behave like hardware.

It's not naive, if you think about inputs as method calls and outputs as continuations. In component-based programming, a component has inputs (i.e. method calls) and outputs (i.e. continuations) that other components can link their inputs to. When components are linked together, they form a circuit where data flows inside it, just like a hardware one.

For example, a web application framework could be easily implemented as a collection of components with inputs and outputs: page requests can be inputs, and page responses can be outputs linked to other page requests after a processing.

Nicola Musatti

Posts: 2
Nickname: nmusatti
Registered: Dec, 2005

Re: The Backside of an Interface Posted: Feb 21, 2006 11:33 AM
Reply to this message Reply
I think that Grogono points to an important problem, but one that I take for granted: each object must do its part correctly, but should be able to trust that the objects it depends upon also do the same.

To put it in another way, conventionally we assign a direction to interfaces: an interface is *provided* by the object that allows access to its methods/attributes and is *used* by the object that calls those methods or accesses those attributes. Grogono says that we should look at interfaces also from the opposite direction. Is there anything to be gained this way? Personally I don't see what.

However there is a related problem that I find more interesting, to which Grogono's analogy appears to fit well. My own analogy is that of a car: a car's public interface is the set of controls we operate when we drive it, but a mechanic also accesses a different interface, one that gives him more power on the car but also more opportunities to cause damage. In OOP that interface is the one we access when we derive from a class.

I find the mental image of a mechanic working underneath a car very effective in reminding us that we should be even more careful when designing the derivable interface of a class, than when we design its public interface, because we're providing a way to make far greater mischief than we do with a class's public interface, that is if we're not careful we might provide a way for subclasses to break the interface's contract, thus shattering the fundamental assumption I made earlier on. In a sense this is a way in which an interface could be considered two sided.

I have to say that if one of these "broken" objects happens to be used as an attribute in the implementation of the original interface we land squarely on the kind of problem Grogono was referring to.

P.S. I learnt programming on Peter Grogono's "Programming in Pascal". Fancy that!

Lars Stitz

Posts: 2
Nickname: stitzl
Registered: Dec, 2005

Re: The Backside of an Interface Posted: Feb 22, 2006 5:21 AM
Reply to this message Reply
What I am missing in the discussion so far is the notion that an interface, both a concrete physical one (on a car or a box) and an abstract one (of a software unit), has a semantic that the implementor must adhere to, or risk breaking functionality. The semantic is what actually makes the interface meaningful, and not the set of method declarations common to all implementing classes. In my opinion, this is what actually goes wrong most of the times in software development, as the semantic of many interfaces is neither specified nor adhered to strictly enough.

For a real world example on underlying semantics, the interfaces of my car's rev meter and of my water boiler's pressure gauge are designed completely similar: round, with numbers from 0-6 distributed evenly spaced on the disc, and a needle that shows the current value. However, the semantics of both instruments are quite different. Another example are the interfaces of two different chargers, which may have exactly identical sets of plugs to the power outlet and the device to be charged, but generate different currents on the later one.

For a programming example of what can go wrong, consider Java's Collection and Iterator interfaces. Now, if I write an Iterator implementation called FilteredIterator, which automatically skips some of the elements of the Collection based on some voodoo algorithm (moonphase, anyone?), and return it from Collection#iterator(), some user might be suprised in the following setting:

/**
 * @returns true if all items of this order are in stock,
 *          or false if we must order an item ourselves.
 */
public boolean allItemsAvailable(Order order) {
  Collection items = order.getItems();
  for (Iterator i = items.iterator(); i.hasNext(); ) {
    OrderItem item = (OrderItem) i.next();
    if (! itemAvailable(item)) {
      return false;
    }
  }
  return true;
}


Now, consider that while it is the general case that Order#getItems() returns a Collection with all order items, some mad hatter created an order with an item collection that returns a FilteredIterator from Collection#iterator() for some reason (or even worse, changed existing code so that this happens). The method sketched above might or might not return the correct value, and it will be completely unclear why, as everyone used the correct interfaces.

The problem is that the Iterator interface and the declaration of Collection#iterator() are, while being very versatile, loosely defined: Should an iterator return all elements of a collection? Does not say so in the documentation, but this is a common expectation. This might be called the downside of an interface.

Cheers, Lars

Mike Petry

Posts: 34
Nickname: mikepetry
Registered: Apr, 2005

Re: The Backside of an Interface Posted: Feb 27, 2006 9:19 AM
Reply to this message Reply
>> When components are linked together, they form a circuit where data flows inside it, just like a hardware one.

I agree that the hardware analogy or metaphor is a powerfull way to visualize interacting components but it is not definitive. Why not a biological methaphor such as wetware? Error handling and intrusion attempts could be handled by the ImmuneSystem and tainted data could be filtered through the Liver. The body is an excellant example of component-based design, with various functions organized in "organs" which interact and share common services such as oxygen, and waste-disposal.

My point is, let these metaphors serve you but do not get hung up on them or let them bound the possible.

piglet

Posts: 63
Nickname: piglet
Registered: Dec, 2005

Vade retro satanas ;-) Posted: Feb 27, 2006 11:58 AM
Reply to this message Reply
C. Diggins:

class MyClass {
  public myFunction() { }
  private MyOtherClass myField;
}
[/pre]
[i]Often people think of the interface of the class as being only "myFunction" but in fact it includes the dependency on "MyOtherClass". What can be a problem is that a call to "myField" could concievably result in a corruption of this.[/i] 
 
This discussion becomes completes nonsense if you start mixing up interface and implementation. The dependency on MyOtherClass is definitely part of the implementation and *not* of the interface. That's what we have all learnt in our first OO lesson. If the point of this back interface "revelation" is the realization that interfaces don't exist in isolation, they also need an implementation which usually depends on other interfaces/components or whatever, wow, who would have thought that. Do you want to convince us to give up or relativize the interface / implementation separation? You are trying to blow up the whole OO enterprise, that's what you are doing! 
 
When I design a database interface, of course there will be wires going out of my "box" connecting it to the database box. But the whole point of wanting a DB interface is to make sure that a client can, and should, use it without caring about those wires, and without caring about which particular DB box it is connected to. Where's the problem with that?

piglet

Posts: 63
Nickname: piglet
Registered: Dec, 2005

Vade retro satanas ;-) Posted: Feb 27, 2006 11:59 AM
Reply to this message Reply
C. Diggins:

class MyClass {
  public myFunction() { }
  private MyOtherClass myField;
}

Often people think of the interface of the class as being only "myFunction" but in fact it includes the dependency on "MyOtherClass". What can be a problem is that a call to "myField" could concievably result in a corruption of this.

This discussion becomes completes nonsense if you start mixing up interface and implementation. The dependency on MyOtherClass is definitely part of the implementation and *not* of the interface. That's what we have all learnt in our first OO lesson. If the point of this back interface "revelation" is the realization that interfaces don't exist in isolation, they also need an implementation which usually depends on other interfaces/components or whatever, wow, who would have thought that. Do you want to convince us to give up or relativize the interface / implementation separation? You are trying to blow up the whole OO enterprise, that's what you are doing!

When I design a database interface, of course there will be wires going out of my "box" connecting it to the database box. But the whole point of wanting a DB interface is to make sure that a client can, and should, use it without caring about those wires, and without caring about which particular DB box it is connected to. Where's the problem with that?

Cleo Saulnier

Posts: 77
Nickname: vorlath
Registered: Dec, 2005

Re: Vade retro satanas ;-) Posted: Mar 5, 2006 5:09 PM
Reply to this message Reply
> When I design a database interface, of course there will
> be wires going out of my "box" connecting it to the
> database box. But the whole point of wanting a DB
> interface is to make sure that a client can, and should,
> use it without caring about those wires, and without
> caring about which particular DB box it is connected to.
> Where's the problem with that?

The problem is the not caring part. Eventually, a programmer will come around who does care and has to maintain these wires. If they're anywhere near as interwined as the wires behind my computer, I pity the fool.

Interfaces were meant to be replaceable. But there's no restriction on its interaction with the rest of the system. That's the real problem. If it does interact with the rest of the system, then you may as well not use an interface because you can't use any other implementation anyhow. If you don't think this is a problem, then I don't know what to say.

BTW, I found out what the black box paradigm is called. It's called Flow Based Programming invented by Paul Morrison in 1969. I wish I had heard of this before. I've decided to give this a try and implement a platform to see if it flies.

http://www.jpaulmorrison.com/cgi-bin/wiki.pl?FlowBasedProgramming

Flat View: This topic has 46 replies on 4 pages [ « | 1  2  3  4 | » ]
Topic: Java Posse Interview part 2 Previous Topic   Next Topic Topic: Are There No Decent Mailing List Programs?


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us