Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > why program to interface is better design?

Reply
Thread Tools

why program to interface is better design?

 
 
jrefactors@hotmail.com
Guest
Posts: n/a
 
      09-29-2005
Is this an example of program to interface?
1) Transaction t = new BankTransaction();

The following only uses the concrete class without the interface
2) BankTransaction t = new BankTransaction();


Is (1) a better choice than (2)? Why is that? (2) and (1) yield the
same output.

public interface Transaction
{
public void deposit(double amt);
}
public class BankTransaction implements Transaction
{
private double balance = 100;
public void deposit(double amt)
{ balance += amt;
}
}
public class BankTransactionTest
{ public static void main(String[] args)
{ Transaction t = new BankTransaction(); //program to interface??
//BankTransaction t = new BankTransaction();
t.deposit(200);
}
}

 
Reply With Quote
 
 
 
 
Roedy Green
Guest
Posts: n/a
 
      09-29-2005
On 28 Sep 2005 22:09:25 -0700, http://www.velocityreviews.com/forums/(E-Mail Removed) wrote or quoted
:

>Is this an example of program to interface?
>1) Transaction t = new BankTransaction();
>
>The following only uses the concrete class without the interface
>2) BankTransaction t = new BankTransaction();
>
>
>Is (1) a better choice than (2)? Why is that? (2) and (1) yield the
>same output.


The advantage of using Transaction is you could later change your code
to Transaction t = new CreditUnionTransaction();

and everything would still work.

The code might not work otherwise because you might have inadvertently
used a BankTransaction method needlessly that CreditUnionTransaction
did not have. Sticking to only the basic Transaction methods is a
sort of a voluntary straight jacket to make your code more pluggable.

IIRC I explain the pluggability advantage further at
http://mindprod.com/jgloss/interface.html
or one of the things it links to.
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.
 
Reply With Quote
 
 
 
 
lqw0205
Guest
Posts: n/a
 
      09-29-2005
//Transaction.java
public interface Transaction{
public void deposit(double amt);
}

//AnotherTransaction.java
public class AnotherTransaction implements Transaction{
private double balance = 100;
public void deposit(double amt){
//Here's different from BankTrasaction
balance -= amt;
System.out.println("AnotherTrasaction.deposit:" + balance);
}
}

//BankTransaction.java
public class BankTransaction implements Transaction{
private double balance = 100;
public void deposit(double amt){
balance += amt;
System.out.println("BankTransaction.deposit:" + balance);
}
}

//BankTransactionTest.java
public class BankTransactionTest{
public static void main(String[] args){
Transaction t1 = new BankTransaction();
Transaction t2 = new AnotherTransaction();
//I don't care about it's a reference of BankTrasaction or
AnotherTrasaction,it works good!
t1.deposit(200); //BankTransaction.deposit:300.0
t2.deposit(200); //AnotherTrasaction.deposit:-100.0
}
}

 
Reply With Quote
 
Andrea Desole
Guest
Posts: n/a
 
      09-29-2005


(E-Mail Removed) wrote:
> Is this an example of program to interface?
> 1) Transaction t = new BankTransaction();
>
> The following only uses the concrete class without the interface
> 2) BankTransaction t = new BankTransaction();
>
>
> Is (1) a better choice than (2)? Why is that? (2) and (1) yield the
> same output.


the previous posts have explained well enough why 1 can be better than
2. Shortly, an interface gives you more abstraction, and makes the code
more flexible and resilient to changes, because you can use different
implementations of the same interface without changing its client.
Still, if you don't think your code will change, or (specially) if you
think your abstraction is good enough, you don't necessarily have to use
solution 1.
In other words: interfaces are good, but before making an interface for
every class think about it
 
Reply With Quote
 
Laurent Bossavit
Guest
Posts: n/a
 
      09-29-2005
> Is (1) a better choice than (2)? Why is that? (2) and (1) yield the
> same output.


I'm wondering why you're appending this note about "yield the same
output". Two competing designs *should* produce the same output - if
they don't, then we choose among the alternatives based on what the
output should be. (In other words, "the requirements" - loosely
speaking.)

Output has nothing to do with how you go about selecting among design
alternatives. (Think of it this way - a Big Mac and an escalope cordon
bleu with gratin also produce the same output, after a while. But I know
which one I'd rather have.)

The question, then, is this: what qualities are you interested in, that
may help you choose between 1) and 2) ?

Laurent
 
Reply With Quote
 
Chris Smith
Guest
Posts: n/a
 
      09-29-2005
<(E-Mail Removed)> wrote:
> Is this an example of program to interface?
> 1) Transaction t = new BankTransaction();
>
> The following only uses the concrete class without the interface
> 2) BankTransaction t = new BankTransaction();
>
>
> Is (1) a better choice than (2)? Why is that? (2) and (1) yield the
> same output.


Good question, actually!

There are, of course, any number of situations in which programming to
the interface is quite beneficial... such as, for example:

public void doDeposit(Transaction t, int amount)
{
if (amount > MAX_DEPOSIT) throw new DepositException();
t.deposit(amount);
}

That's nice because you could pass any kind of Transaction and still end
up with the same result. This is reuse of code, avoids duplication, and
I think everyone can agree that it's better design than to write two
different methods where one takes a BankTransaction and the other a
CreditTransaction, if we assume that the requirements being enforced are
the same for both.

In your case, though, you've both created and used a reference within
the same method. Really, it hardly matters in that situation. If
anything, the one slight reason for choosing the interface is just to
develop a habit of using abstraction when it's available to you. But
even that is rather dubious. It makes almost no difference from any
kind of practical perspective that I can see.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
 
Reply With Quote
 
Andrea Desole
Guest
Posts: n/a
 
      09-29-2005


Laurent Bossavit wrote:

> Output has nothing to do with how you go about selecting among design
> alternatives. (Think of it this way - a Big Mac and an escalope cordon
> bleu with gratin also produce the same output, after a while. But I know
> which one I'd rather have.)


definitely a Big Mac. No, okay, I was not serious.
Besides that, I'm sure some people would just say "well, it's all food".
This is also the mentality some people have when they write software:
"it works, so it's enough". Several times I tried to convince some of
these people that it's not enough. Never been very successful
 
Reply With Quote
 
Laurent Bossavit
Guest
Posts: n/a
 
      09-29-2005
Andrea,

> > alternatives. (Think of it this way - a Big Mac and an escalope cordon
> > bleu with gratin also produce the same output, after a while. But I know
> > which one I'd rather have.)

>
> definitely a Big Mac. No, okay, I was not serious.
> Besides that, I'm sure some people would just say "well, it's all food".


Yes, and that's fine. People might think like that.

The fact of the matter is that gourmet food is a huge business, so there
is market value in doing quality work. Similarly I believe there is
market value in software that has internal quality, regardless of how it
behaves externally.

The other fact of the matter is that BigMac food is also a huge
business, so there is market value in churning out identical product at
a known level of intrinsic quality - even if that quality is low
(negative, if you consider health issues).

> This is also the mentality some people have when they write software:
> "it works, so it's enough". Several times I tried to convince some of
> these people that it's not enough. Never been very successful


I've tried a different tack: don't try to convince people, but pick and
choose the people I associate with among those who are already convinced
that it's not enough that the program produces the expected output. Not
quite as easy as it sounds, but it works for me.

Laurent
 
Reply With Quote
 
Thomas G. Marshall
Guest
Posts: n/a
 
      09-29-2005
(E-Mail Removed) coughed up:
> Is this an example of program to interface?
> 1) Transaction t = new BankTransaction();
>
> The following only uses the concrete class without the interface
> 2) BankTransaction t = new BankTransaction();
>
>
> Is (1) a better choice than (2)? Why is that? (2) and (1) yield the
> same output.
>
> public interface Transaction


The other posts here are enough. However, you should understand that
"program to interface" does not specifically mean java interface.

The term "interface" is an OO concept. If you had, say, language with no
"interface" keyword/construct like java has, then you would still be able to
program to interface, by programming specifically to the highest level
superclass (perhaps abstract) you can that supplies the methods
(interface/functionality) you need.

....[rip]...


 
Reply With Quote
 
Thomas G. Marshall
Guest
Posts: n/a
 
      09-30-2005
Andrea Desole coughed up:
> Laurent Bossavit wrote:
>
>> Output has nothing to do with how you go about selecting among design
>> alternatives. (Think of it this way - a Big Mac and an escalope
>> cordon bleu with gratin also produce the same output, after a while.
>> But I know which one I'd rather have.)

>
> definitely a Big Mac. No, okay, I was not serious.
> Besides that, I'm sure some people would just say "well, it's all
> food". This is also the mentality some people have when they write
> software: "it works, so it's enough". Several times I tried to
> convince some of these people that it's not enough. Never been very
> successful


Sometimes you will have a customer that just wants you to produce just that:
something that works, and will only pay for that much. Forget the lofty
goals of maintainability and reusability. Forget the hoity concepts of
clear headed design. (all sarcasm). The point is, a contractor is often
left without a choice. The same goes for salaried personel under an absurd
deadline. Go in, do it, get out.

Many times people seem to act as if time is never a factor in design. It
almost /always/ is.


 
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
why why why why why Mr. SweatyFinger ASP .Net 4 12-21-2006 01:15 PM
findcontrol("PlaceHolderPrice") why why why why why why why why why why why Mr. SweatyFinger ASP .Net 2 12-02-2006 03:46 PM
Is splint really better than lint? Is there a better tool than splint? Peter Bencsik C Programming 2 09-21-2006 10:02 PM
Build a Better Blair (like Build a Better Bush, only better) Kenny Computer Support 0 05-06-2005 04:50 AM
Why doesn't the better camera have a better dpi? Tony Carlisle Digital Photography 6 10-04-2003 10:40 AM



Advertisments