Interface and Implementation

In object-oriented programming, a lot of emphasis is placed on knowing the interface and implementation. from a book, i come across this piece of code

public class IntSquare {

  //private attribute
  private int squareValue;

  //public interface
  public int getSquare(int value) {
 
    squareValue = calculateSquare(value);

    return squareValue;
  }

  //private implementation
  private int calculateSquare(int value); {
 
    return value * value;
  }
}

the reason giving was to separate implementation from interface so as to hide details from users, and the implementation without affecting the user.

i was thinking if it is ok to write the above code in the following manner

public class IntSquare {

    public int getSquare(int value) {
 
    return value*value;
  }
}


i find it more concise and lesser code to be written, or is there something that i have missed out? i think the first method is good if there are other methods in the class that need to use the calculateSquare method

comments?

eddy
Sunday, February 29, 2004

Of course your example is better.  In fact, it'd be even better just to write a global function to handle that task, since it's not inherently stateful.  Really it's a bad example to work from.

K
Sunday, February 29, 2004

Whatever book that is, throw it away. The author is clearly an idiot.

Brad Wilson (dotnetguy.techieswithcats.com)
Sunday, February 29, 2004

Yes separating interface and implementation can be a powerful technique, but that example is a horrible mis-use of it.

Reminds me of a Java homework assignment I saw at a major university that required the students to write stateful classes for trivial stateless operations like multiplying arrays.

Dan Maas
Sunday, February 29, 2004

Isn't it possible the author was purposefully using a trivial example just to illustrate the concept?

Mike Treit
Sunday, February 29, 2004

even if he wants to show that, book authors should indicate that the given class is a bad design or not.

one of the reasons this world has so many lame programmers is that their first experience is a f...ing lame code, but at that time they cannot realize that. after that they learn that and it will be a habit to create classes like the above one.

grrhh.

Sunday, February 29, 2004

"Isn't it possible the author was purposefully using a trivial example just to illustrate the concept?"

It's possible that that's what he intended. Of course, he failed miserably, because he clearly doesn't even KNOW what it means to separate interface and implementation, which is why the book should be burned. :-p

Brad Wilson (dotnetguy.techieswithcats.com)
Sunday, February 29, 2004

eddy,

Do you remember the title of that book? I'd like to know so I can be sure to *NEVER* buy it.

Joe
Sunday, February 29, 2004

Whoever wrote this doesn't get "separate interface and implementation".  Here's a proper example:

public interface IntSquareCalculator
{
    public int getSquare( int value );
}

public class MyIntSquareCalculator implements IntSquareCalculator
{
    public int getSquare( int value ) {
        return value*value;
    }
}

Why is this a proper example?  Because a user of IntSquareCalculator doesn't care what the implementation does: it only cares about the contract provided by IntSquareCalculator.  The implementation could be as above, it could be an invocation of a Web Service, it could be a lookup table, etc.

This is what is meant by separation of interface and implementation: the user is separated from the implementation by the interface.  The interface provides a contract, and that's all.  The implementation provides a concrete mechanism for fulfilling that contract, and that's all.

-Thomas

Thomas
Sunday, February 29, 2004

Well written Thomas.  I would only add that the only reason one would want to do this in the given example is if he thinks that different implementers of the getSquare method might want to do it in different ways.  It seems unlikely.

name withheld out of cowardice
Sunday, February 29, 2004

replace getSquare with getUserProfile and it makes a lot more sense.

Maybe the UserProfile could come from a web service, database call, flat file or even hard coded for running in unit tests.  Now you may not see the value here, but if you've coded your application to call the database, then someone decides that the firewall rules shouldn't allow the server to query the database directly (I'm speaking from experience) then you can replace it another implementation without *too much* heart ache.

This is more what seperating interface and implementation is about.

Koz
Sunday, February 29, 2004

thanks for the help.
btw is there any good books that explain clearly the use of interface and implementation?

eddy
Monday, March 1, 2004

"Design Patterns explained" might fit your request.

Pakter
Monday, March 1, 2004

The idea is very simple: your methods/functions should not require knowledge of their implementation to be used. 

So when you're presented with a method/function square(), you should be able to make use of it without having to worry about setting some global variable, passing values in a certain way, having member variables overwritten, etc.:

int square(int x) {
...
}

The interface here is: "int square(int x)".  That's all you, the user of the function, need to know.  That "..." is the implementation, the part you need to know nothing about.  It may just multiply "x", it may use a special assembly instruction for speed, it may have some clever caching, but it's not important to you.

Please keep in mind that one does not need to write the Java keyword 'interface' to construct an interface.  The concept is more general.  For example, when you go to this website you access it through HTTP.  The site may be written in Perl or ASP or PHP, but the interface remains HTTP.

Matt
Wednesday, March 3, 2004

  Recent Topics

  Fog Creek Home