why program to interface is better design?

Discussion in 'Java' started by jrefactors@hotmail.com, Sep 29, 2005.

  1. Guest

    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);
    }
    }
    , Sep 29, 2005
    #1
    1. Advertising

  2. Roedy Green Guest

    On 28 Sep 2005 22:09:25 -0700, 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.
    Roedy Green, Sep 29, 2005
    #2
    1. Advertising

  3. lqw0205 Guest

    //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
    }
    }
    lqw0205, Sep 29, 2005
    #3
  4. 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
    Andrea Desole, Sep 29, 2005
    #4
  5. > 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
    Laurent Bossavit, Sep 29, 2005
    #5
  6. Chris Smith Guest

    <> 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
    Chris Smith, Sep 29, 2005
    #6
  7. 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
    Andrea Desole, Sep 29, 2005
    #7
  8. 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
    Laurent Bossavit, Sep 29, 2005
    #8
  9. 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]...
    Thomas G. Marshall, Sep 29, 2005
    #9
  10. 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.
    Thomas G. Marshall, Sep 30, 2005
    #10
  11. Roedy Green Guest

    On Fri, 30 Sep 2005 01:15:55 GMT, "Thomas G. Marshall"
    <> wrote or quoted
    :

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


    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Again taking new Java programming contracts.
    Roedy Green, Sep 30, 2005
    #11
  12. 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
    Laurent Bossavit, Sep 30, 2005
    #12
  13. Roedy Green wrote:
    > On Fri, 30 Sep 2005 01:15:55 GMT, "Thomas G. Marshall"
    > <> wrote or quoted
    > :
    >
    >> 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.


    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.

    --
    Do or do not. There is no try.
    Yoda
    Ulrich Hobelmann, Sep 30, 2005
    #13
  14. Thomas G. Marshall wrote:
    >
    > 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
    Andrea Desole, Sep 30, 2005
    #14
  15. Roedy Green Guest

    On Fri, 30 Sep 2005 09:59:20 +0200, Ulrich Hobelmann
    <> wrote or quoted :

    >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.
    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Again taking new Java programming contracts.
    Roedy Green, Sep 30, 2005
    #15
  16. 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.)


    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
    Berislav Lopac, Sep 30, 2005
    #16
  17. 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.

    --
    "His name was Robert Paulson. His name was Robert Paulson. His name was
    Robert Paulson..."
    Thomas G. Marshall, Sep 30, 2005
    #17
  18. Andrea Desole coughed up:
    > Thomas G. Marshall wrote:
    >>
    >> 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.


    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.


    > By the way: I'm not a contractor, so this is more an employee's point
    > of view


    --
    "His name was Robert Paulson. His name was Robert Paulson. His name was
    Robert Paulson..."
    Thomas G. Marshall, Sep 30, 2005
    #18
  19. 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
    Laurent Bossavit, Sep 30, 2005
    #19
  20. Laurent Bossavit coughed up:
    > Thomas,
    >
    >> This is pedantic silliness.

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


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


    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.


    --
    "Well, ain't this place a geographical oddity!
    Two weeks from everywhere!"
    Thomas G. Marshall, Sep 30, 2005
    #20
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Mr. SweatyFinger

    why why why why why

    Mr. SweatyFinger, Nov 28, 2006, in forum: ASP .Net
    Replies:
    4
    Views:
    855
    Mark Rae
    Dec 21, 2006
  2. Mr. SweatyFinger
    Replies:
    2
    Views:
    1,756
    Smokey Grindel
    Dec 2, 2006
  3. JoeC

    Better program design?

    JoeC, Aug 23, 2006, in forum: C++
    Replies:
    23
    Views:
    666
  4. Jim Janney
    Replies:
    43
    Views:
    1,010
    Arved Sandstrom
    May 15, 2011
  5. Steven Simpson
    Replies:
    5
    Views:
    331
Loading...

Share This Page