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 | » ]
Cleo Saulnier

Posts: 77
Nickname: vorlath
Registered: Dec, 2005

Re: The Backside of an Interface Posted: Feb 11, 2006 8:07 AM
Reply to this message Reply
Advertisement
> > 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?

Well, in one way it should complement what's already available and in another it should define the way we write certain applications.

There are two issues at hand here.

1. Requirements. (What does this black box need to complete its operation?)
2. Input/Output. (What kind of data can it process and what format will it be when it comes out?)

Right now, interfaces define both the input and output. But the output is usually restricted to return values or "byref" parameters. That's not good. In C++, the return value isn't even part of the method's identity.

Seperation of functionality and its data is fundamental to any replaceable modularity. Why we would want to group them together is beyond me. Data should come in two types. One is data that gets passed around and the other is in more permanent storage (such as lists, arrays or even databases). When the data gets passed around, then it is given to "processing stations" that YOU the programmer have set up in a chain. So you can pick and choose the best algorithms and at the end of the chain, your data is in the form that you want it.

Some call all this component based programming, some stream based, some unix based, some pipeline based. There doesn't seem to be a consensus. All I know is that Unix style programming went to the wayside a long time ago for reasons unknown. It has proved itself time and again, but never got formalised. I'm sure people wanted more power and flexibility, but to throw it completely away was not the smartest move IMHO. It's a shame that OOP has made this kind of programming virtually impossible.

Mike Petry

Posts: 34
Nickname: mikepetry
Registered: Apr, 2005

Re: The Backside of an Interface Posted: Feb 11, 2006 11:10 AM
Reply to this message Reply
Its a little naive to think that a software component would behave like hardware. The term "black box" as a definition of a software component is a metaphor.

Interfaces provide several benefits. As noted, the interface provides encapsulation as it controls the access to the inner workings of software functionality.
Also interfaces define a contract of services that an implementing component must provide.
Interfaces (like in Java) or abstract base classes (C++) can be used to realize the true power of polymorphism. The true power of polymorphic components is decoupling.
As far as I can tell, next to meeting the requirements of your product, decoupling is the most important consideration for any software design.
Interfaces are not a panacea. Class, components and thier constituent elements such as interfaces go along way towards managing the complexity of software but software remains to be very complex indeed.
Some of the arguments presented here seem to be advocating up front, UML based design. One of the primary benefits of UMLs class diagrams is to show associations between the various components of a software design.

Marc Loxton

Posts: 9
Nickname: spoonchops
Registered: Feb, 2006

Re; the whole electrical comparison Posted: Feb 12, 2006 8:26 PM
Reply to this message Reply
IMHO the original comparison with an electrical component in a box is flawed logic in any case.

A box front panel should be likened to a UI layer not an Interface, the backside of the panel with wires is the UI linking to interfaces, the circuitry is the implementation of those interfaces.

I agree that the implementation of such interfaces can rely on many other objects and the underlying code may not be as loosely coupled as it would seem from the Interface layer but I think the initial comparison made here is a mistake.

disney

Posts: 35
Nickname: juggler
Registered: Jan, 2003

Re: Re; the whole electrical comparison Posted: Feb 13, 2006 5:17 AM
Reply to this message Reply
I may be very stupid, but I can't see what the fuss is about. Can someone give me an example of these 'stealth interfaces' that are causing such excitement? Thanks.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: The Backside of an Interface Posted: Feb 13, 2006 9:51 AM
Reply to this message Reply
> Seperation of functionality and its data is fundamental to
> any replaceable modularity. Why we would want to group
> them together is beyond me. Data should come in two
> types. One is data that gets passed around and the other
> is in more permanent storage (such as lists, arrays or
> even databases). When the data gets passed around, then
> it is given to "processing stations" that YOU the
> programmer have set up in a chain. So you can pick and
> choose the best algorithms and at the end of the chain,
> your data is in the form that you want it.

I am interested in what you are saying here but I have some doubts about this.

I know that I can chain interfaces as they exist. I find that chaining of components is much simpler when the chain is unidirectional. What it sounds like to me is that you are talking about are bidirectional interfaces. In my experience, having bidirectionality in a design is generally to be avoideded. It increases coupling and the complexity of the system.

If I have three interfaces A, B, and C, I can easily chain them together by creating an implementation of A that accepts a B as a constructor and an implementation of B that takes a C as a constructor. How does what you are describing improve upon that?

thanks,

James.

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: Re; the whole electrical comparison Posted: Feb 13, 2006 10:02 AM
Reply to this message Reply
> I may be very stupid, but I can't see what the fuss is
> about. Can someone give me an example of these 'stealth
> interfaces' that are causing such excitement? Thanks.

I should clarify that what Peter and I were talking about were not interfaces, in the sense of Java but rather:

"A point at which independent systems or diverse groups interact".

The interface of a class is traditionally thought of as being its public member functions and public fields. However, the classes that it depends on (i.e. uses, imports or inherits), are also part of its interface.

The analogy is akin to my printer in that it, it has on the front a power button, a form feed button, and a change ink button. However this is incomplete to describe the interface. The interface also include the power cord, usb printer cable, and paper feeder.

In a more concrete example:

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.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Re; the whole electrical comparison Posted: Feb 13, 2006 10:39 AM
Reply to this message Reply
class MyClass {
  private final MyOtherClass myField;
 
  public MyClass(final MyOtherClass backInterface)
  {
      myField = backInterface;
  }
   
  public myFunction() { }
}


Why isn't the above a solution?

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: Re; the whole electrical comparison Posted: Feb 13, 2006 11:53 AM
Reply to this message Reply
>
> class MyClass {
>   private final MyOtherClass myField;
> 
>   public MyClass(final MyOtherClass backInterface)
>   {
>       myField = backInterface;
>   }
>    
>   public myFunction() { }
> }

>
> Why isn't the above a solution?

There really isn't a solution to be had. I am simply making the observation that a formal or informal specification of a class's 'interface' should also include the classes upon which it depends.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Re; the whole electrical comparison Posted: Feb 13, 2006 12:09 PM
Reply to this message Reply
> There really isn't a solution to be had. I am simply
> making the observation that a formal or informal
> specification of a class's 'interface' should also include
> the classes upon which it depends.

How does the above not do that?

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: Re; the whole electrical comparison Posted: Feb 13, 2006 12:18 PM
Reply to this message Reply
> > There really isn't a solution to be had. I am simply
> > making the observation that a formal or informal
> > specification of a class's 'interface' should also
> include
> > the classes upon which it depends.
>
> How does the above not do that?

What you posted was the class implementation, not a specification of the class's interface.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Re; the whole electrical comparison Posted: Feb 13, 2006 1:09 PM
Reply to this message Reply
> > > There really isn't a solution to be had. I am simply
> > > making the observation that a formal or informal
> > > specification of a class's 'interface' should also
> > include
> > > the classes upon which it depends.
> >
> > How does the above not do that?
>
> What you posted was the class implementation, not a
> specification of the class's interface.

I consider the constructor to be part of a classes 'interface'. Care to explain how it is not? You can just look at the signature of the constructor if the implementation is distracting.

If you are saying that we want to specify what an interface (in the Java sense) needs to work, I disagree. How would I know what someone else's implementation needs when specifying the interface?

Max Lybbert

Posts: 314
Nickname: mlybbert
Registered: Apr, 2005

just nod and say "yes" Posted: Feb 13, 2006 2:16 PM
Reply to this message Reply
/* [cdiggins] I am simply making the observation that a formal or informal specification of a class's 'interface' should also include the classes upon which it depends.

[James Watson] How does the above not do that?
*/

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. If your text editor highlights the private parts of a class in chartruse, there's a chance you'll miss this, because it's just a detail that most of the time is overlooked because, most of the time, it's not important. But when it's important, you feel stupid for spending all your time chasing the wrong thing.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: just nod and say "yes" Posted: Feb 13, 2006 2:45 PM
Reply to this message Reply
> 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. If your text
> editor highlights the private parts of a class in
> chartruse, there's a chance you'll miss this, because it's
> just a detail that most of the time is overlooked because,
> most of the time, it's not important. But when it's
> important, you feel stupid for spending all your time
> chasing the wrong thing.

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

Jeff Ratcliff

Posts: 242
Nickname: jr1
Registered: Feb, 2006

Re: Re; the whole electrical comparison Posted: Feb 13, 2006 5:31 PM
Reply to this message Reply
It doesn't make too much sense to me on the hardware side either.

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). The requirements of the "backside" (e.g. speaker outputs) would not be a factor, nor would the components used within the amplifier. All that would matter would be that the interface of interest be described correctly and that I met its requirements.

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: Re; the whole electrical comparison Posted: Feb 13, 2006 5:54 PM
Reply to this message Reply
> It doesn't make too much sense to me on the hardware side
> either.
>
> 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). The requirements of the "backside" (e.g.
> speaker outputs) would not be a factor,

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).

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