I thought this was worth reposting from the comments of my previous IFoo post.
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
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
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
ReportEventListener, which should also be the interfaces used by the Engine and the Gui respectively.
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
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.