4 ms·

I'm torn on this. I agree in principle with the article, but what I've seen in practice having worked on different projects (mostly Java) is a lot of one interf

by Yhippa 4y ago

I'm torn on this. I agree in principle with the article, but what I've seen in practice having worked on different projects (mostly Java) is a lot of one interface to one implementation class. The interface and the implementation ends up being nearly the same. Along comes a need for a second implementation years later. Now you have to figure out how to match the interface but also do some serious refactoring to truly make the interface more generalizable. It is easy to say that doing it up front to genericize functionality in an interface but in practice I've seen that it's difficult to do right. When I create a new interface I hope that I did my best job with abstraction and that I give the least amount of rework to future developers.

marginalia_nu 4y ago
I think the purpose of (Java) interfaces should be primarily seen as a means to decouple code that shouldn't be tightly coupled, rather than a means to offer polymorphism. It's relatively rare that multiple implementations of the same interface is desirable, it definitely happens, but not too much. It's a bit of a balance. Decoupling can definitely be taken too far. Anyone who has worked in the language has no doubt encountered the ravioli code left by someone who has just read Clean Code and has fully embraced Uncle Bob as their lord and savior. In the end the need for this interface-as-decoupling pattern has dropped significantly with modern dependency injection and ad-hoc mocking libraries like Mockito. They grant most the benefits of these single-child interfaces with virtually none of the drawbacks.
przemo_li 4y ago
Generalization is a way to go forward. Years back, they didn't even dreamed about your new class. Refactoring isn't waste. Its what enables good code this time around. (And what avoided mistaken decisions back then as someone just assumed stuff will be refactored) But those whole years compilation speed benefited greatly (because in Java interface is a cutoff for incremental compilation - in Java interface is THE developer experience).

by Yhippa 4y ago

marginalia_nu 4y ago

I think the purpose of (Java) interfaces should be primarily seen as a means to decouple code that shouldn't be tightly coupled, rather than a means to offer polymorphism. It's relatively rare that multiple implementations of the same interface is desirable, it definitely happens, but not too much. It's a bit of a balance. Decoupling can definitely be taken too far. Anyone who has worked in the language has no doubt encountered the ravioli code left by someone who has just read Clean Code and has fully embraced Uncle Bob as their lord and savior. In the end the need for this interface-as-decoupling pattern has dropped significantly with modern dependency injection and ad-hoc mocking libraries like Mockito. They grant most the benefits of these single-child interfaces with virtually none of the drawbacks.

przemo_li 4y ago

Generalization is a way to go forward. Years back, they didn't even dreamed about your new class. Refactoring isn't waste. Its what enables good code this time around. (And what avoided mistaken decisions back then as someone just assumed stuff will be refactored) But those whole years compilation speed benefited greatly (because in Java interface is a cutoff for incremental compilation - in Java interface is THE developer experience).