An example of why IFoo as Foo’s interface is evil and should be punished.

I thought this was worth reposting from the comments of my previous IFoo post.

Anybody who does not work in the conventions used by the project is undoing the team’s hard the work to build a clean codebase with a common domain language. Agile methods stress common code ownership for a reason — it’s extremely hard to work on code that is a patchwork of the individual styles chosen by prima donna programmers. The worst project that I have had the misfortune to work on recently had different coding styles used within individual files! Anbody who does not work with the team in this respect should NOT BE ON THE TEAM, end of story.

IFoo is used because someone thought of a Foo class and created an interface to go with it. That kind of thinking doesn’t lead to clean code in the first place.

Here’s an example, using the IFoo interface notation:

I create a Gui class and an IGui interface, so that the Gui can listen to the events from the Engine, which implements the IEngine interface.

Because of threading issues, I decide to create an EventQueueHandler, which can manage the events passed between one and the other. To enable it to talk to both it now has to implement both the IEngine and the IGui interface.

The EventQueueHandler is neither an Engine nor a Gui.

This is what I’m trying to avoid by cursing the use of IFoo. It’s pretty easy to see that this is wrong, but in more complex code the roles can be lost amidst the functionality. What the EventQueueHandler‘s actually doing is listening to the ReportEvents fired by the Engine and the RequestEvents fired by the Gui, so it should be implementing RequestEventListener and ReportEventListener, which should also be the interfaces used by the Engine and the Gui respectively.

Call them IRequestEventListener and IReportEventListener if you absolutely have to, as per the comments on my previous IFoo post, but please consider blazing a new trail of code convention in your chosen language. If you really, truly can’t allow developers to call them anything other than IGui and IEngine then you won’t want me on your team anyway.

The reason I can come up with this example is because I actually did this (with a different naming convention that was easier to hide). I only realised my mistake when I plugged the EventQueueHandler in. I am, as a result of these thoughts, also convinced of the evils of DefaultFoo, and, in fact, of the use of “Foo” in example code. Foo is meaningless. It’s a point which was made to me before and I didn’t listen.

This entry was posted in Uncategorized. Bookmark the permalink.

9 Responses to An example of why IFoo as Foo’s interface is evil and should be punished.

  1. anonymous says:

    What this is about is the granularity of interfaces, not the fact that there’s an IGui and IEngine interface.

    There is no reason at all not to create the RequestEventListener and ReportEventListener interfaces. As soon as you have a client to a class/type which only cares about a logically consistent subset of the whole, you’ve got a driver to extract a smaller interface out.

    Robert, twasink.net

  2. anonymous says:

    You quote a comment describing why you should work in a common convention for the good of the team and then follow it with this request that programmers do NOT follow the common convention:

    “please consider blazing a new trail of code convention in your chosen language”

    Are you one of those prima donna programmers that make the lives of their teammates such a misery?

  3. anonymous says:

    Common convention for a team != common convention for a language.

  4. anonymous says:

    It should at least be based on the common conventions of the language, or the code is a mishmash of styles wherever it interfaces to standard libraries or any other third-party code.

    I guess the conclusion is that prima donna teams are just as bad as prima donna programmers.

  5. anonymous says:

    >>Because of threading issues, I decide to create an EventQueueHandler, which can manage the events passed between one and the other. To enable it to talk to both it now has to implement both the IEngine and the IGui interface.
    <<
    Doesn't make sense why can't they both just implement some IEventGobbler interface? Abstract roles not objects, it's quiet simple…

  6. sirenian says:

    No; I’ve been told repeatedly that I’m a pleasure to work with. I’ve enjoyed working with the vast majority of people I’ve met; such things tend to be reciprocal.

    Consider means “think about”, not “do”. I worked on a (Java) project in which we stopped using the company-wide convention of tagging interfaces with ‘I’. It was highly successful.

    I certainly want to get away from the main Java APIs’ practice of DefaultTableCellRenderer for the TableCellRenderer implementation.

    New ideas are not a threat, just an opportunity.

  7. sirenian says:

    Convention, obviously – if you have a Foo class, its interface must be IFoo.

    Oh, wait. You’re right. (So am I, once I get round to renaming everything further down the post – cookies all round!)

    NB: I separated the types of event because otherwise certain types of event – eg: new game selection – got confusing. Did something just request a new game, or did something just start it? Since the functionality for the two listeners had to be run in separate threads anyway, it was no overhead to have two different classes of events, and listeners for each kind.

    In Java 1.5 you could certainly use the same interface for both classes and use generics to type them.

  8. anonymous says:

    Actually, there can be advantages to making 3rd-party code distinctly obvious; it tells you when you’re working stuff under the team’s control and when you’re not.

  9. anonymous says:

    That’s kind of obvious from the package and class names!

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s