4 ms·

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'

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.

vips7L 3y ago
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.
- za3faran 3y ago
  I've seen the same in golang, which ironically is supposed to be vehemently against OOP.
- rjbwork 3y ago
  >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...
  - hadrien01 3y ago
    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.
diarrhea 3y ago
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.
- zamalek 3y ago
  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.
- hadrien01 3y ago
  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.
rowls66 3y ago
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.

vips7L 3y ago

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.

za3faran 3y ago
I've seen the same in golang, which ironically is supposed to be vehemently against OOP.
rjbwork 3y ago
>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...
- hadrien01 3y ago
  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.

diarrhea 3y ago

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.

zamalek 3y ago
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.
hadrien01 3y ago
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.

rowls66 3y ago

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.