Java Interface Implementation Tip #1: Don’t.

By Robert Fischer | Published: December 27, 2007

Okay, new rule: if you’re only going to have one implementation, don’t have a friggin’ interface. I’m sick of having to hunt down your “FooBeanImpl” class (which, of course, I need to get from the singleton “FooBeanImplProviderFactory”) whenever I just want to work with a “Foo”.

Related posts:

  1. Another Person Bit by Java Exposing the Implementation through Inheritance
  2. Implementation Exposure Through Inheritance
  3. Extending Java Syntax
  4. Java Goes Scripting
  5. Why Java Wants Closures
This entry was posted in To Be Categorized and tagged . Bookmark the permalink. Post a comment or leave a trackback: Trackback URL.
  • Brian

    This is the side effect of having a static, nominal class system with no multiple inheritance. Sure, the current code base only has one implementation of Foo, but not having the interface confines future code directions. Although this plays into my discussion of use vr.s reuse- what we’re arguing about here is to what extent should the initial use cases include having other implementations of a given interface?

    Another point I’d like to make here is that this is why language design decisions can not be made in isolation- they all interact. Java ditched multiple inheritance based upon the experience with C++, most notably the “where the fsck did this member come from?” problem. The problem with this is that it just shoved all the type hackery that in C++ would be dealt with with MI into the interfaces. But this only works if every type is an interface…

    Personally, I’m moving away from OO generally. Outside of maybe GUI programming, I just don’t see the point. There’s no big advantage to being able to say foo.bar instead of bar foo- and the OO method implies that there is only one bar I’ll ever want to call on this foo.

    Actually, thinking about it, I’m not even sure that GUIs wouldn’t be better handled with modules and functors. It’s certainly an interesting approach.

  • Categories