9

I recently started working with a shiny new version of a codebase that uses interfaces all over for... basically everything. I think all of our concrete classes implement interfaces.

The problem I've noticed is that the project doesn't appear to code to the interface! Items passed using interfaces are consistently casted to specific types. This feels like a bad idea but I can't seem to articulate clearly why this is wrong. It seems like using interfaces only to cast regularly is losing the benefits of both interfaces and a strongly-typed language in the first place.

To rephrase as a question: Is this a good practice? Why?

Edit: This is not a duplicate of What is the point of having every service class have an interface? as my question relates specifically to casting from an interface to a dozen or more concrete classes that implements that interface.

Community
  • 1
William
  • 274
  • 2
  • 8
  • 1
    No its bad practice. The whole idea of the interface is to enable you to replace the class you are passing in with something else. – Ewan Feb 24 '17 at 16:40
  • Out of curiosity: Does the code use methods of the casted object, that the interface does not implement? – Tekay37 Feb 24 '17 at 16:41
  • @Tekay37 - The common approach seems to be to cast to a concrete class, then use that freely, with all its fields and methods and such. – William Feb 24 '17 at 16:54
  • Possible duplicate of [What is the point of having every service class have an interface?](http://softwareengineering.stackexchange.com/questions/150045/what-is-the-point-of-having-every-service-class-have-an-interface) – gnat Feb 24 '17 at 17:21
  • @gnat - We _also_ have that problem, but this is separate. – William Feb 24 '17 at 22:33

2 Answers2

15

This is bad practice no matter you slice it.

If the code nominally expects an interface but then casts the parameter to a concrete type in order to use methods more specific than the interface, then it is effectively lying to itself. Presumably had to follow a well-intentioned guideline such as "All parameter types musty be interfaces" and followed its letter but not spirit, probably for lack of understanding.

If the values are cast and then used only via functionality of the interface anyway, that's even weirder. It looks as if someone doesn't understand the concept of interfaces at all and thinks they can only use (or only understand the use of) objects when they know their concrete class.

Both are red flags, although the second case is a bigger red flag.

Kilian Foth
  • 107,706
  • 45
  • 295
  • 310
2

If all you know about an object is that it conforms to some interface, then you should assume that it may be an instance of at least two different classes that implement this interface.

I have used interfaces where there were actually three different classes implementing the interface, and casting to the wrong class would have been desastrous. And I have used interfaces where another class was substituted for testing purposes, again casting to the wrong class would have been desastrous.

Now if you call an interface method, that call will end up in the code of a particular concrete class. Within that concrete class you will know what concrete implementation is being used for this particular object, so there you don't need to program against the interface for this object.

gnasher729
  • 42,090
  • 4
  • 59
  • 119