why program to interface is better design?
 

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);
}
}

Re: why program to interface is better design?
 

On 28 Sep 2005 22:09:25 -0700, jrefactors@hotmail.com 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.

Re: why program to interface is better design?
 

//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
}
}

Re: why program to interface is better design?
 

jrefactors@hotmail.com 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

Re: why program to interface is better design?
 

> 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

Re: why program to interface is better design?
 

<jrefactors@hotmail.com> 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

Re: why program to interface is better design?
 

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

Re: why program to interface is better design?
 

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

Re: why program to interface is better design?
 

jrefactors@hotmail.com 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]...

Re: why program to interface is better design?
 

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.