Hacker News Reader

Comment by hadrien01 | Hacker News Reader

The language doesn't push you towards interfaces implemented once, but many developers indeed persist doing it for no reason at all. With proper code review we're able to make that practice go away on the projects I'm working on.

View on HN

Isn't this just mostly an issue with mock testing in C#? Developers cargo cult single implementation interfaces because its so hard to mock concrete classes.

I've seen the same in golang, which ironically is supposed to be vehemently against OOP.

>Isn't this just mostly an issue with mock testing in C#

Yes. You have two choices: Interface implemented once, or virtual on all your public members.

I personally think Interface is the sane choice.

Would be nice if the .NET devs let us mock POCO's though...

You can mock (well, "fake") POCOs with packages like AutoFixture that use reflection to generate mostly fake data, depending on what you need. You don't need interfaces or virtual, but you do need public getters unfortunately.

Lots (all?) major frameworks push for dependency injection though, where interfaces are a must, as far as I know (not for DI-the-principle, but DI-as-implemented). ASP.Net Core is a good example. It's not C# at the language level forcing interface-driven development, but frameworks like ASP.Net are so tightly integrated that boundaries blur.

You don't need interfaces for dependency injection, you can inject classes directly. I see interfaces more for separation of concerns (with domain-driven design pushed from all parts in the .NET world at the moment...), but that's not an obligation.

Yup, that's what I meant by "practically." Nobody forces you to use the Microsoft.x nuget packages, but good luck at finding packages that don't rely on Microsoft.DI, or Microsoft.Hosting, or what-have-you.

I have seen way too much of interfaces implemented once in Java, and have argued against it unsuccessfully many times. I am not working in Go, and see the same.

Reply on news.ycombinator.com