why program to interface is better design?

J

jrefactors

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

Roedy Green

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

lqw0205

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

Andrea Desole

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
 
L

Laurent Bossavit

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
 
C

Chris Smith

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
 
A

Andrea Desole

Laurent said:
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
 
L

Laurent Bossavit

Andrea,
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
 
T

Thomas G. Marshall

(e-mail address 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]...
 
T

Thomas G. Marshall

Andrea Desole coughed up:
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.
 
R

Roedy Green

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.

I think we ought to think of ourselves more like dentists. The
patient can say all they want about their wishes, but it is up to you
to interpret them in a way you don't actually harm the patient.

The same applies to architects and boat builders. You have a
professional duty not to build something dangerous even if your idiot
customer asks you to.
 
L

Laurent Bossavit

Thomas,
The point is, a contractor is often left without a choice.

[The choice to do quality work]

I submit that the contractor *has* a choice. Always. And interestingly,
there is an interesting cross-thread connection to the discussion of
software-as-craft. A craftsman is one who *knows* he has that choice.
The same goes for salaried personel under an absurd deadline. Go in,
do it, get out.

If the deadline is unrealistic, the project will fail. To agree to do
the project under these conditions is to be complicit in the failure. In
these conditions, we should exercise our choice not to take part in the
project.

Laurent
 
U

Ulrich Hobelmann

Roedy said:
I think we ought to think of ourselves more like dentists. The
patient can say all they want about their wishes, but it is up to you
to interpret them in a way you don't actually harm the patient.

Yes, a hippomatic OOath would be cool.
The same applies to architects and boat builders. You have a
professional duty not to build something dangerous even if your idiot
customer asks you to.

Problem is, if you say "but we need time for testing, and it costs this
much" then the guy goes to someone else. Nevermind that someone else
can't do the job properly, and that it'll actually cost MORE than you
said you would charge, but the other guy ends up with the money.

In many cases, the customer will even pay the someone else MORE after
missing the deadline. Funny that the contracts don't seem to mention
delivery for fixed price. At least that's what usually happens with
projects initiated by the German government.
 
A

Andrea Desole

Thomas said:
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.

I agree with that, and I have to say that sometimes you have something
small to implement, without special enhancements needed later. In that
case you don't have to do fancy things: when the application works, you
are done, and nothing else is needed.
But often this is not the case, and people don't understand that fast,
good and cheap don't go together. If something works now they don't
think about what will happen in one or two years. If you want a long
term project, or worse, a product, this is not the way to proceed. I'm
not against hacking, the first thing is always to get a result. But if
you hack it now, you will have to fix it later, or you are probably not
going to get any more results.
And the worst thing is: when people just don't care, and the situation
gets slowly worse and worse, and people start panicking, guess who is
going to fix it?
By the way: I'm not a contractor, so this is more an employee's point of
view
 
R

Roedy Green

In many cases, the customer will even pay the someone else MORE after
missing the deadline.

There is some saying that goes something like, there is always
time/money/budget to fix a problem but never to prevent it.

It is not just computers. Look at the Katrina costs now that could
have been saved with a little more prevention.
 
B

Berislav Lopac

Laurent said:
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.)

While hilarious, this comparison is totally off-mark. If we compare software
systems to bodily functions, the food in your example has nothing to do with
systems design -- it's just a different kinds of input, one being a giant
Word file with no formatting consistency, hundreds of various fonts,
space-based tables and untested data, and the other being a neat XML format
with a cleanly designed DTD and carefully checked data. The fact that our
system can parse and produce the same output from both (although with some
unwanted side effects in one case) just proves that the system is
well-designed overall.

Berislav
 
T

Thomas G. Marshall

Laurent Bossavit coughed up:
Thomas,
The point is, a contractor is often left without a choice.

[The choice to do quality work]

I submit that the contractor *has* a choice. Always. And
interestingly, there is an interesting cross-thread connection to the
discussion of software-as-craft. A craftsman is one who *knows* he
has that choice.
The same goes for salaried personel under an absurd deadline. Go in,
do it, get out.

If the deadline is unrealistic, the project will fail. To agree to do
the project under these conditions is to be complicit in the failure.
In these conditions, we should exercise our choice not to take part
in the project.

This is pedantic silliness.

If someone wants a painter to paint their house, but only do a quick single
coat, because they cannot afford to scrape, prime and dual coat it, is the
painter supposed to say "no no, that is not up to what I'm normally able to
do" ?

A customer might /need/ a crap project put together in haste.

Anyone who knows me in this newsgroup, and in others, knows the extent to
which I greatly value properly written code. I often painfully describe out
core issues that have been missed by posters in a strong attempt to get them
to understand the issue. But *do* *not* *romanticize* what we are doing: we
are doing a service/product for a customer, and as such, if the customer
/thinks/ he can afford only a sloppy blindingly quickly put-together
project, then stamping your feet and saying "no" is simply childish.
 
T

Thomas G. Marshall

Andrea Desole coughed up:
I agree with that, and I have to say that sometimes you have something
small to implement, without special enhancements needed later. In that
case you don't have to do fancy things: when the application works,
you are done, and nothing else is needed.
But often this is not the case, and people don't understand that fast,
good and cheap don't go together.

Oh absolutely! And sometimes you are just simply not able to get past that:
sometimes their money just isn't there, or they have budgeted just for
something of X quality, where X is far less than what you would normally
consider ideal.

If something works now they don't
think about what will happen in one or two years. If you want a long
term project, or worse, a product, this is not the way to proceed. I'm
not against hacking, the first thing is always to get a result. But if
you hack it now, you will have to fix it later, or you are probably
not going to get any more results.
And the worst thing is: when people just don't care, and the situation
gets slowly worse and worse, and people start panicking, guess who is
going to fix it?

{shrug} Presumably the same person who made it will be /paid/ to fix it.
 
L

Laurent Bossavit

Thomas,
This is pedantic silliness.

Worse to come, I'm afraid. Save yourself the trouble and killfile me
right now, don't read ahead.
If someone wants a painter to paint their house, but only do a quick single
coat, because they cannot afford to scrape, prime and dual coat it, is the
painter supposed to say "no no, that is not up to what I'm normally able to
do" ?

Now *that* would be self-serving arrogance. What the painter probably
means to say is something like, "The extra coat is going to peel off in
a matter of months and you'll have to do it over again, except this time
the scraping will be more of a pain so you'll end up paying more."

(I don't know the first thing about painting, so I'm just pushing the
metaphor, but the thing is - we know that crap software always ends up
costing more and taking longer.)
A customer might /need/ a crap project put together in haste.

Let's put it this way: I've never come across this situation. I've seen
crap projects that did not have serious consequences - but that was
always because something *worse* happened to the business, so that the
crap project itself became irrelevant. All the other crap projects I've
seen ended up hurting everyone - client and perpetrator, er, I mean
contractor.

I have never, ever seen a situation where a customer said "This can be
quick and dirty", dirty was delivered quick, and the customer clearly
benefited from it. ("Quick and dirty" should not be confused with "Quick
and just enough to be better than nothing", which does work.)

If you have, I'm interested in hearing your story.
But *do* *not* *romanticize* what we are doing: we
are doing a service/product for a customer, and as such, if the customer
/thinks/ he can afford only a sloppy blindingly quickly put-together
project, then stamping your feet and saying "no" is simply childish.

Yes, and I'm not suggesting we do that. There are at least three things
we can do. One is to find better clients. Another is to overtly agree to
doing a sloppy job, then covertly do a worthwhile job in the same time
and budget. (I've done that and seen it done.) A third is to find out
why the client is in that bind, and figure out alternative solutions. A
fourth is to first educate the client. Etc...

If the customer /thinks/ he can afford a sloppy blindingly quickly put-
together project, then bowing your head and complying is simply not
mature.

Laurent
 
T

Thomas G. Marshall

Laurent Bossavit coughed up:
Thomas,


Worse to come, I'm afraid. Save yourself the trouble and killfile me
right now, don't read ahead.

Why? I regard your opinions as fairly worthwhile.

Now *that* would be self-serving arrogance. What the painter probably
means to say is something like, "The extra coat is going to peel off
in a matter of months and you'll have to do it over again, except
this time the scraping will be more of a pain so you'll end up paying
more."

Sure. And the customer says "ok". The painter's supposed to refuse to do
it? How is this different that saying: This project is going to work for
now but 1. not be very maintainable, 2. cost you more later, and 3. irk me
no end. If the customer understands this, (taking human safety related
software off the table---that's a anomoly to this discussion) I see no
reason to not do as the customer wants---unless you romanticise this, there
is no moral nor ethical issue here at all.

Nor have you shown me why I should refuse.

....[rip]...

Yes, and I'm not suggesting we do that. There are at least three
things we can do. One is to find better clients.

Again: why? There is a waste deep moral implication in your words that you
do not elaborate on. This is a service. Go back to the painter. Why *not*
produce the product that the customer needs at the time?

Another is to
overtly agree to doing a sloppy job,

So you *have* seen a customer ask for that.

then covertly do a worthwhile
job in the same time and budget. (I've done that and seen it done.) A
third is to find out why the client is in that bind, and figure out
alternative solutions. A fourth is to first educate the client. Etc...

If the customer /thinks/ he can afford a sloppy blindingly quickly
put- together project, then bowing your head and complying is simply
not mature.

And that statement is plainly naive.

Have you ever seen a customer in a startup situation that needs to get a
product that works to market as incredibly soon as possible? I have.
Repeatedly. In this case, the emphasis is getting the damn thing out the
door. Often that bites the customer hard, but sometimes that only bites the
customer later. Sometimes getting the thing to market regardless of the
internal invisible quality of the code is the only way he can get his
company to the next stage!!!!

Again, take the romanticism out of it. There is no reason that you have
stated that you cannot do as a customer (that knows the issues) wants/needs.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top