YAGNI vs "Program to interfaces rather than concrete implementations"

[pulkitent]

YAGNI (You aren't going to need it) rule says we should have the minimum number of elements in our code to do the job.

But whenever I create a class it's recommended that we should first create an interface and then extend it by having a child class as per the principle "Program to interfaces rather than concrete implementations" so that I can accommodate future requirements better and have more loosely coupled code.

But according to YAGNI, from the beginning, we should avoid creating unnecessary interfaces.

So which to follow and when to follow? Usecase?

[pulkitent]

@valentinacupac would you like to share your thoughts here?

[valentinajemuovic]

@pulkitent I only use the keyword "interface" (Java & .NET) in the following cases:

• I'm abstracting an I/O concern, so then the interface helps me replace real implementation by test double
• There are multiple variants of an implementation, for example with the strategy pattern I have an interface for the algorithm execution, which specifies input and output... and then concrete classes do implementations

Now in the past, I did have interfaces for nearly everything (that was back in the days when I was testing classes in isolation, so I'd put all the collaborators as interfaces). I don't do that anymore.

[tedyoung]

Agree with @valentinacupac here. We can actually simplify that rule with:

Only create an interface when there is more than one concrete implementation. Note: a Test Double (stub, spy, etc.) counts as an implementation.

Abstracting I/O (e.g., Ports in the Hexagonal Architecture) are always interfaces for testability purposes, if nothing else. However, even inside your Domain, you may have interfaces representing abstractions. For example, with a "pizza ordering system" you might have a bunch of different toppings that can go on a pizza, as well as other options (deep dish? corn meal crust? thick crust? etc.), all of which affect pricing, so they all may implement a PricedOption interface, even though they're otherwise unrelated.

p.s. If you see lots of classes ending in -Impl (e.g., PriceCalculatorImpl), you probably have an interface that's not needed. If you can't think of a good name for the concrete class, you may have an interface that's not needed, but sometimes I'll keep it and name the implementation Default- (e.g., DefaultPriceCalculator).

[PCreations]

YAGNI is about deferring choice to the last responsible moment so you can focus on delivering value right of the bat. To be able to let you defer this kind of choices, your code need to be modular and have low coupling. Thus, YAGNI forces you to have a more modular code to be a able to replace it later with a real implementation whenever the right technology has been chosen. Hence the needed interface to abstract away your program intent :)

[tedyoung]

But to follow YAGNI, you would only create the interface at the point that you need that flexibility. To introduce an interface because of "modularity" or "flexibility" might be premature.

One of the great things about languages like Java is the ease of extracting an interface from an existing implementation. IntelliJ IDEA makes this almost trivial.

Where an interface might be needed up-front is if it's used as an entry point into a module or library of code, where you don't have control/access to the code that might use it. That means you want to abstract any incoming dependencies, i.e., create an interface.