Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Style and practice question: use of interfaces

Reply
Thread Tools

Style and practice question: use of interfaces

 
 
Richard C. Cobbe
Guest
Posts: n/a
 
      07-26-2005
Greetings, all.

I have a question for the Java programming community at large.

For years, the software engineering curriculum has been telling us to
program to interfaces, rather than to implementations, and the benefits of
this involve reasons we've all heard before: encapsulation, low coupling,
better maintainability, and so forth. This is a widespread,
non-controversial point, and I'd guess that anybody who's had even a little
formal training in programming has heard this before.

With Java, programmers can actually use the language's interface
construction to separate the interface from the implementation and actually
realize the style described above. But that doesn't seem to be what's
happening -- some colleagues and I have looked at various Java projects and
found that people don't actually do this.

So, why the disconnect between theory and practice? What practical issues
come up to encourage people to program to classes?

I'd love to hear your thoughts on this.

Thanks much,

Richard
 
Reply With Quote
 
 
 
 
jan V
Guest
Posts: n/a
 
      07-26-2005
> So, why the disconnect between theory and practice? What practical issues
> come up to encourage people to program to classes?
>
> I'd love to hear your thoughts on this.


I recently worked for a company with a very odd take on the Java interfaces
thing. In a complex library consisting of 500+ heavily inter-dependent
types, more than a third of those were interfaces. As someone with many
years of Java experience (nearly 10) I had never seen such a high
interface/classes ratio. A ratio of 1:20 feels "normal", 1:10 would feel
"high", but 1:3 felt wrong from day one (for me).

As I got to learn this company's library, and started to work on code which
used the library, I was horrified to see that this company's own "engineers"
almost invariably did NOT code to the interfaces, but to the concrete
classes instead.

It transpired that writing an interface, but not actually using it (the way
it's mean to be used), is part of that company's "culture". Go figure...


 
Reply With Quote
 
 
 
 
Stefan Ram
Guest
Posts: n/a
 
      07-26-2005
http://www.velocityreviews.com/forums/(E-Mail Removed) (Richard C. Cobbe) writes:
>I'd love to hear your thoughts on this.


I did so recently, when I was working on a Java implementation
of state monads.

I wanted to defined the "bind" operation for a state monad.

First, I used interfaces to define what a state, value,
product-and-state-pair, operation and parameterized operation
is:

interface StateType {};

interface ValueType {};

interface ProductAndState<ValueType,StateType>
{ ValueType getProduct();
StateType getState(); }

interface Operation<ValueType,StateType>
{ ProductAndState<ValueType,StateType> execute( StateType state ); }

interface ParameterizedOperation<ValueType,StateType,Paramet erType>
{ Operation<ValueType,StateType> asDeterminedBy( final ParameterType parameter ); }

Now, I can define the bind-operation using only these interfaces:

class Bind<ValueType,StateType,ProductType>
{ Operation<ValueType,StateType> firstOperation;
ParameterizedOperation<ProductType,StateType,Value Type> secondOperation;
Bind
( final Operation<ValueType,StateType> firstOperation,
final ParameterizedOperation<ProductType,StateType,Value Type> secondOperation )
{ this.firstOperation = firstOperation;
this.secondOperation = secondOperation; }
Operation<ProductType,StateType> composition()
{ return new Operation<ProductType,StateType>()
{ public ProductAndState<ProductType,StateType> execute( final StateType initialState )
{ ProductAndState<ValueType,StateType> intermediateProductAndState =
firstOperation.execute( initialState );
return secondOperation.asDeterminedBy( intermediateProductAndState.getProduct() )
.execute( intermediateProductAndState.getState() ); }}; }}

Finally, I can implement the interfaces and use the bind operation
on the implementations:

class MemoryState implements StateType
{ MemoryState( final int value ){ this.value = value; }
int value;
public int getValue(){ return this.value; }}

class IntValue implements ValueType
{ IntValue( final int value ){ this.value = value; }
public int asInt(){ return this.value; }
int value; }

class IntProductAndMemoryState implements ProductAndState<IntValue,MemoryState>
{ final IntValue product;
final MemoryState state;
IntProductAndMemoryState( final IntValue product, final MemoryState state )
{ this.product = product; this.state = state; }
public IntValue getProduct(){ return product; }
public MemoryState getState(){ return state; }}

class IntValueOperation implements Operation<IntValue,MemoryState>
{ final IntValue value;
IntValueOperation( final IntValue value ){ this.value = value; }
public ProductAndState<IntValue,MemoryState>
execute( final MemoryState state )
{ return new IntProductAndMemoryState( value, state ); }}

class ReaderOperation implements Operation<IntValue,MemoryState>
{ ReaderOperation(){}
public ProductAndState<IntValue,MemoryState>
execute( final MemoryState state )
{ return new IntProductAndMemoryState
( new IntValue( state.getValue() ), state ); }}

class WriterOperation implements Operation<IntValue,MemoryState>
{ IntValue value; WriterOperation( final IntValue value )
{ this.value = value; }
public ProductAndState<IntValue,MemoryState>
execute( final MemoryState state )
{ return new IntProductAndMemoryState
(( IntValue )null, new MemoryState( value.asInt() )); }}

class ReadValue
implements ParameterizedOperation<IntValue,MemoryState,IntVal ue>
{ public Operation<IntValue,MemoryState> asDeterminedBy( IntValue value )
{ return new ReaderOperation(); /* ignores the value */ }}

class WriteValue
implements ParameterizedOperation<IntValue,MemoryState,IntVal ue>
{ public Operation<IntValue,MemoryState> asDeterminedBy( IntValue value )
{ return new WriterOperation( value ); /* writes the value */ }}

class Monade
{
static Operation<IntValue,MemoryState> bind
( final Operation<IntValue,MemoryState> first,
final ParameterizedOperation<IntValue,MemoryState,IntVal ue> second )
{ return new Bind<IntValue,MemoryState,IntValue>( first, second ).composition(); }
static Operation<IntValue,MemoryState> value( final int i )
{ return new IntValueOperation( new IntValue( i )); }

static ParameterizedOperation<IntValue,MemoryState,IntVal ue> writeValue()
{ return new WriteValue(); }
static ParameterizedOperation<IntValue,MemoryState,IntVal ue> readValue()
{ return new ReadValue(); }

public static void main( final String[] _ )
{ final MemoryState initState = new MemoryState( 0 );
final int initValue = 2;
ProductAndState<IntValue,MemoryState> productAndState =
bind( bind( value( initValue ), writeValue() ), readValue() ).
execute( initState );
java.lang.System.out.println( productAndState.getProduct().asInt() ); }}

So, this technique would be:

- first, define the types (interfaces)
- then, define all algorithms on these types (interfaces)
- finally, define "thin" implementations using the types and
algorithms defined in the previous steps

However, the same result can be achieved using refactoring by
factoring out algorithms and interfaces from a thick
implementation.

(An additional nice idea would be to use a multimethod
framework for the algorithms. So that the implementations
might use a multi-argument run-time dispatch in cases,
when this is helpful.)


 
Reply With Quote
 
Thomas Hawtin
Guest
Posts: n/a
 
      07-26-2005
Richard C. Cobbe wrote:
>
> For years, the software engineering curriculum has been telling us to
> program to interfaces, rather than to implementations, and the benefits of
> this involve reasons we've all heard before: encapsulation, low coupling,
> better maintainability, and so forth. This is a widespread,
> non-controversial point, and I'd guess that anybody who's had even a little
> formal training in programming has heard this before.
>
> With Java, programmers can actually use the language's interface
> construction to separate the interface from the implementation and actually
> realize the style described above. But that doesn't seem to be what's
> happening -- some colleagues and I have looked at various Java projects and
> found that people don't actually do this.


I think there is a widespread misunderstanding between interface the
general concept and Java interface types.

Every Java class has an interface. It just so happens to be conveniently
bundled with the code for easy construction and maintenance.

Don't confuse Java interfaces with C header files. They do completely
different things. In fact I believe Java kicked off with the idea of
getting rid of header files.

"Programming to the interface" is no more or less hard if it's to a the
interface of an interface or an interface of a class. You can make
assumptions about the implementation either way. (Although a class has
more ways to expose its implementation. The easy solution to that is
don't write you classes badly.)

I once worked for a company where the core of the new product had been
written such that pretty much every class had an associated interface.
Trying to deal with the code base drove programmers to distraction.
Apart for the bloke who designed it that way. He wouldn't be my first
choice employee.

Tom Hawtin
--
Unemployed English Java programmer
http://jroller.com/page/tackline/
 
Reply With Quote
 
Roedy Green
Guest
Posts: n/a
 
      07-27-2005
On Tue, 26 Jul 2005 16:43:46 -0400, (E-Mail Removed) (Richard C.
Cobbe) wrote or quoted :

>With Java, programmers can actually use the language's interface
>construction to separate the interface from the implementation and actually
>realize the style described above. But that doesn't seem to be what's
>happening -- some colleagues and I have looked at various Java projects and
>found that people don't actually do this.


What ARE they doing?

--
Bush crime family lost/embezzled $3 trillion from Pentagon.
Complicit Bush-friendly media keeps mum. Rumsfeld confesses on video.
http://www.infowars.com/articles/us/...s_rumsfeld.htm

Canadian Mind Products, Roedy Green.
See http://mindprod.com/iraq.html photos of Bush's war crimes
 
Reply With Quote
 
Roedy Green
Guest
Posts: n/a
 
      07-27-2005
On Tue, 26 Jul 2005 20:59:02 GMT, "jan V" <(E-Mail Removed)> wrote or quoted
:

>As I got to learn this company's library, and started to work on code which
>used the library, I was horrified to see that this company's own "engineers"
>almost invariably did NOT code to the interfaces, but to the concrete
>classes instead.


The theory is classes are for insiders, interfaces are hooks for
outsiders. Sound like they are not properly hooking up their
interfaces though.

--
Bush crime family lost/embezzled $3 trillion from Pentagon.
Complicit Bush-friendly media keeps mum. Rumsfeld confesses on video.
http://www.infowars.com/articles/us/...s_rumsfeld.htm

Canadian Mind Products, Roedy Green.
See http://mindprod.com/iraq.html photos of Bush's war crimes
 
Reply With Quote
 
Roedy Green
Guest
Posts: n/a
 
      07-27-2005
On Tue, 26 Jul 2005 22:13:44 +0100, Thomas Hawtin
<(E-Mail Removed)> wrote or quoted :

>"Programming to the interface" is no more or less hard if it's to a the
>interface of an interface or an interface of a class. You can make
>assumptions about the implementation either way. (Although a class has
>more ways to expose its implementation. The easy solution to that is
>don't write you classes badly.)


The idea of an interface is that is exposes a bare minimum
functionality to get the job done. A class spills out everything.

An interface makes it easier to plug in a replacement. There are
fewer glue points and less temptation to build more spider webs that
necessary.

So you might have several interfaces on the same class, depending what
role it is playing.

I primarily think of interfaces as places where I want to plug in
different code or might want to in future. The classic example is a
set of dynamic classes all of which implement a common interface.
Think of the JCE or JDBC driver scheme where vendors can plug their
implementations into the official Java system.


--
Bush crime family lost/embezzled $3 trillion from Pentagon.
Complicit Bush-friendly media keeps mum. Rumsfeld confesses on video.
http://www.infowars.com/articles/us/...s_rumsfeld.htm

Canadian Mind Products, Roedy Green.
See http://mindprod.com/iraq.html photos of Bush's war crimes
 
Reply With Quote
 
HK
Guest
Posts: n/a
 
      07-27-2005
Richard C. Cobbe wrote:
> With Java, programmers can actually use the language's interface
> construction to separate the interface from the implementation and actually
> realize the style described above. But that doesn't seem to be what's
> happening -- some colleagues and I have looked at various Java projects and
> found that people don't actually do this.


You mean people use

HashMap bla = new HashMap();
ArrayList urx = new ArrayList();
public void doThings(HashSet oompf) { ... }

instead of

Map bla = new HashMap();
List urx = new ArrayList();
public void doThings(Set oompf) { ... }

Well, it took me some time to get used to the latter.
I guess it is a matter of experience and a lack of
formal help from the compiler.

Harald.

------------------------------------------------------------------------
BioMed Information Extraction: http://www.ebi.ac.uk/Rebholz-srv/whatizit

 
Reply With Quote
 
Richard C. Cobbe
Guest
Posts: n/a
 
      07-27-2005
Roedy Green <(E-Mail Removed)> writes:

> On Tue, 26 Jul 2005 16:43:46 -0400, (E-Mail Removed) (Richard C.
> Cobbe) wrote or quoted :
>
>>With Java, programmers can actually use the language's interface
>>construction to separate the interface from the implementation and actually
>>realize the style described above. But that doesn't seem to be what's
>>happening -- some colleagues and I have looked at various Java projects and
>>found that people don't actually do this.

>
> What ARE they doing?


Pretty much just using the classes directly, and ignoring the frequent
disconnect between a class's intended interface and its actual one.

Richard
 
Reply With Quote
 
Richard C. Cobbe
Guest
Posts: n/a
 
      07-27-2005
"HK" <(E-Mail Removed)> writes:

> Richard C. Cobbe wrote:
>> With Java, programmers can actually use the language's interface
>> construction to separate the interface from the implementation and
>> actually realize the style described above. But that doesn't seem to be
>> what's happening -- some colleagues and I have looked at various Java
>> projects and found that people don't actually do this.

>
> You mean people use
>
> HashMap bla = new HashMap();
> ArrayList urx = new ArrayList();
> public void doThings(HashSet oompf) { ... }
>
> instead of
>
> Map bla = new HashMap();
> List urx = new ArrayList();
> public void doThings(Set oompf) { ... }


That's pretty much what we've seen, yes.

> Well, it took me some time to get used to the latter.
> I guess it is a matter of experience and a lack of
> formal help from the compiler.


I'm also interested in how you work with the classes that you yourself
write. Our experience is that most people tend not to define interfaces
for them and simply use the class names directly, as in your first example
above.

Richard
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Interfaces and exceptions, best practice question Jama Java 18 06-06-2006 03:28 AM
Why do so many new style ansi streams and files etc, still use old style strings? Kza C++ 4 03-03-2006 07:00 PM
Remember when your piano teacher taught you, "Practice, practice,practice ...?" Wayne Wastier Windows 64bit 3 06-10-2005 08:29 PM
best practice for designing navigation interfaces Simon HTML 14 01-02-2005 09:09 AM
Need help with Style conversion from Style object to Style key/value collection. Ken Varn ASP .Net Building Controls 0 04-26-2004 07:06 PM



Advertisments