Hacker News Reader

Comment by anonyfox | Hacker News Reader

I think I still would have to deal with a lot of OOP and imperative code there, C# feels like a kitchen sink of stuff - right?

View on HN

C# is horribly OOP. I use it in my day job, and the frameworks wield OOP overcomplexity proudly. It has likely gone beyond Java as the posterchild for OOP: interfaces that are implemented once, classes that are instantiated once. You can't get away from it either, it is practically part of the stdlib and everyone cargocults it.

Rust is imperative too, though.

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.

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.

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.

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.

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.

You can avoid quite a bit of OOP with Kotlin if you like, and with Arrow make some really nice functional code. Imo it offers a great balance of imperative vs functional, providing powerful tools for whatever style suits the project best.

Reply on news.ycombinator.com