4 ms·
I work in a primarily C# shop. I am often quite annoyed at some of coworkers code due to it being what I feel is needlessly over abstracted. I don't know if it'
by ixwt 6y ago
I work in a primarily C# shop. I am often quite annoyed at some of coworkers code due to it being what I feel is needlessly over abstracted. I don't know if it's my lack of experience with this style of code, or perhaps I don't know the concept of OOP as well as I should. But it is quite aggravating.
- criddell 6y agoI think it's the frameworks. If you are using something like .Net Core it really encourages you to break everything up into services that can be selected via dependency injection and you naturally seem to end up several layers. I'm sure there are times when that's absolutely the way to go, but something simpler that solves the problem directly will often do.
- mpfundstein 6y agowhereby the only injection ususally is the same servuce over and over. with the occassional DatabaseMock sometimes...
- marsven_422 6y agoUnit testing is not "sometimes" is 50% if the code you write
- mpfundstein 6y agoin your dreams maybe :-) (not to say that this wouldnt be a good thing)
- thrower123 6y agoThe way Asp.net encourages inscrutable code through spooky action-at-a-distance dependency injection patterns is one of the things I actively dislike about working with C#. Fortunately, you can avoid most of it and be more explicit if you want, it's just not the idiomatic way. There's almost always an escape hatch to ditch the overblown abstraction layers and get down to what's actually happening. If all else fails there's dotPeek and Reflector...
- marsven_422 6y agoAnd thus killing of the ability to do proper unit testing.
- thrower123 6y agoIf that pattern is required for proper unit-testing, I don't want to do 'proper' unit testing. You can write code where your dependencies are injected and can be swapped out for testing without buying into a framework that makes it that difficult to reason about what code is actually being run and in what order.
- noisy_boy 6y agoI don't have experience with .NET core but taking example of Spring in Java (which gets targeted a lot for this sort of thing), you can get away with putting the logic at the outer levels without using services. However, more often then not, you end up using similar chunks of related functionality that then gets put into some common class to avoid repeating it everywhere. If you are already doing that, then why not put them in a service - its just a class with a @Service annotation that the dependency injection can take advantage of. Further, the fact that services are logical containers of such related functionality, creating them actually follows the principle of least surprise (viz. audit related stuff goes in AuditService) and testing/mocking etc becomes cleaner. Of course, if you are writing a simple utility, then none of this is necessary - you'll probably not use Spring for it anyway and just core Java is fine.
- sunstone 6y agoAbstraction if necessary but not necessarily abstraction. That's my rule of thumb.