Skip to content

Programming to Interfaces

March 19, 2009

Matt was having problems with getting fruit. He’d written a method to get fruit, but was feeding it the fruit class, i.e. Banana b = getFruit(Banana.class); Having recently done something similar myself, I pointed out that you don’t have to tell your generic method twice that you need a banana (once in the argument, and again in the return type); it’s sufficient to just ask for a Banana b = getFruit(); and have it give you a banana. So I asked him…

[dan] how’s your generic coming along?
[matt] i’ve left it for time being
[d] meh
[m] you were right about Banana b = getFruit();
[m] of course
[m] obvious now
[m] if i was to do that now, my yucky implementation would have to look something utterly disgusting like this:
private T getFruit() throws RemoteException
T type = (T) new Object();
Class c = type.getClass();

[m] then using c to get fruit out of map
[d] your point being?… leave the interface screwed because fixing the interface first makes your crappy implementation even crappier? and the reason we program to interfaces is because we leave them broken to support crappy implementations, until their usage is so widespread that fixing the interface breaks too much code?
[m] good point
[m] well put
[m] i just don’t like having dirty underwear
[m] but I’d rather have heavily soiled undies so long as people thought they were clean
[d] the point about hiding your underwear is that no-one can see the skidmarks
[m] if this isn’t the basis for a blog anecdote I don’t know what is
[m] (or do i mean metaphor)
[m] (or analogy)
[d] I’m already on it

2 Comments leave one →
  1. March 20, 2009 11:00 am

    My “utterly disgusting” example code above wouldn’t actually work because Class c would be an Object Class. How would I get the type of the given class…?

    But, ignoring that, if I change the signature to just

    public <T extends Fruit> T getFruit()

    Then assuming the method peel() was available on Bananas but not all Fruit I could do:
    Banana b = getFruit();

    But I couldn’t do:

    Am I just being particularly stupid or does all this just seem wrong?

  2. dan permalink
    March 20, 2009 4:30 pm

    The more I think about this, and hack together bits of test code, the more I think we’ve got this whole thing cart-before-horse. The whole point of having a FruitFactory is that it gives you Fruit, and you use the Fruit as Fruit, and you don’t care whether it’s a Banana or a Pomegranate or a Pear. That’s the job of the system configurator; whoever it is who decides that you, as a FruitSmoothyMaker, is going to take Bananas today and Pears tomorrow.

    If you need a banana, and you’re programmed to take bananas, then this isn’t the pattern for you.

    So I stand by my original point, which is, don’t preserve a broken interface because it supports a crappy implementation. Fix the interface, even if your implementation gets even more broken in the process. You’re going to have to fix that implementation someday anyway.

    As for the specific example, it’s poorly formed, and somewhat buried within a wider post. Perhaps I ought to break it out into a conversation all of its own…

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: