0

I am struggling with applying the "programming to an interface" guideline because I can't seem to decide in which situations it is necessary and in which ones it's overkill (or even counter productive).

I would like to know of any heuristics or rules that you use in your projects to decide if you need to create a new interface and use it instead of an specific class.

Just to clarify, note that the question is not about the benefits of this guideline or the importance of following it. It's about some basic rules you use to know when to use it and when not to.

carlossierra
  • 1,405
  • 3
    see also: Understanding “programming to an interface” – gnat Jun 26 '16 at 15:12
  • @gnat thanks for the references, but please see that I am not asking for an explanation of the benefits or to know if it has to be applied in one particular case. What I need to know is if you have specific rules/heuristics you follow on a daily basis to decide when and when not to follow this guideline. (Btw, i read those questions and some others before posting, and I don't think they answer my question). – carlossierra Jun 26 '16 at 15:35
  • rule of thumb / heuristics is YAGNI, this is covered in multiple answers in the duplicate including the top one – gnat Jun 26 '16 at 15:40
  • 4
    "Program to an interface" doesn't mean "program to the Java interface keyword." It means, essentially, "Respect the API contract." When do you do that? Always. Read Telastyn's answer carefully. – Robert Harvey Jun 26 '16 at 16:19
  • @gnat how would you write that sentence to make it more general? Because it was meant just as an example. I want the answer to the concept, independent of the language. Should I just remove it? – carlossierra Jun 26 '16 at 23:45
  • language independent question and answer on this matter was referred in this comment by @RobertHarvey - "When do you do that? Always" – gnat Jun 26 '16 at 23:53
  • @RobertHarvey to me it means that I need to program to the abstraction instead of an specific implementation or materialization of that abstraction. But the problem with this (and your linked answer) is that sometimes there are very specific classes that are very unlikely to require an abstraction layer, so maybe in those cases it is YAGNI. The heuristics I'm looking for are for being able to properly determine when those situations arise. – carlossierra Jun 26 '16 at 23:58
  • Asked in a different way: do you guys create an abstraction every time you create a new class? If not, why? When? – carlossierra Jun 27 '16 at 00:05
  • By abstraction, do you mean interface or abstract class? Or do you simply mean the API of the implementing class? – Robert Harvey Jun 27 '16 at 00:05
  • @RobertHarvey both... They both represent a concept that implementing classes or sub-classes need to embrace and materialize. – carlossierra Jun 27 '16 at 00:06
  • OK. Well, you can program against a class's API without ever involving an interface. It's a sensible thing to do since, if you're going to go to all the trouble to write a class for its OO benefits like encapsulation, then you might as well respect the API it offers. Does that make sense? – Robert Harvey Jun 27 '16 at 00:07
  • Correspondingly, you add an interface when you want the benefits its offers. The primary benefit of an interface is to establish an API by which you can write more than one implementation. This allows you to do things like substitute a mock object or double for testing purposes. The mock object is your alternate implementation. – Robert Harvey Jun 27 '16 at 00:09
  • @RobertHarvey would you care to provide all your advice in a full response? I think we are establishing here that this is a more general question. I am willing to edit my question, as I said before, to make it more clear for others coming here. – carlossierra Jun 27 '16 at 00:10
  • 1
    I'm just concerned that you're confusing the interface that the "programming to an interface" guideline describes with the interface that is provided in some programming languages. See http://www.fatagnus.com/program-to-an-interface-not-an-implementation/. – Robert Harvey Jun 27 '16 at 00:12
  • @RobertHarvey I see you edited a comment you made above after I posted my reply. I meant that to me abstraction can be interface or abstract class. Not an api (which I understand as a contract I need to follow to use some particular class). – carlossierra Jun 27 '16 at 00:16
  • 2
    @carlossierra Generally, an interface means the surface of something. In programming, it's whatever a component provides for consumption and manipulation by other components, like those you might write. Such an interface consists of everything the provider says belongs to it, no more, no less: Names (or absence thereof), constants, functions, classes, whatever, and their behavior. Beware though that existence of something does not make it part of the interface. – Deduplicator Jun 27 '16 at 00:40

0 Answers0