Unpopular opinion
-
In one of the gaming forum that I frequent, they like to post so called "unpopular opinion" thread, and then proceed to say something everybody agrees on... ;P Anyway, while idly driving to work this morning I got stuck by an idea and I am going to try my own take on the unpopular opinion meme. See whether I am also, mistakenly, posting what is in fact a popular opinion! ^_^ So.. here I go. Short story: From a C# dev to another C# dev. I hate interfaces. Long story: ok, ok, sorry, I got nothing against interface in principle. They could be quite useful :) . It's just that in practice I have seen so many projects with zillion of interfaces with zillion of methods which are only implemented once. Worst, sometimes some of those methods implementation can be derived on the other method and if one would implement the interface twice there would be a lot of copy paste :/ But what really take the cake and I unambiguously despise is the argument that it helps "testability" (using mocks! ho god, mocks, I hate thee so). From what I have seen those people are stickler for "unit test" (as opposed to "integration test") which basically only test the mock that you spend hours writing and make refactoring difficult, but don't really test the application... And it is often white box testing (I know it's implemented this way, that's why I write that test) which contribute to making refactoring a pain. This is worst than waste of time. It also make future developer also waste time.
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
IMHO, most software is way over architectured and is more about showcasing some gee-whiz-bang new and totally unnecessary library than actually solving the problem. These things are really nice maintenance nightmares for those that follow behind - I love having to flip through a dozen code files to get to the actual implementation tho.
-
In one of the gaming forum that I frequent, they like to post so called "unpopular opinion" thread, and then proceed to say something everybody agrees on... ;P Anyway, while idly driving to work this morning I got stuck by an idea and I am going to try my own take on the unpopular opinion meme. See whether I am also, mistakenly, posting what is in fact a popular opinion! ^_^ So.. here I go. Short story: From a C# dev to another C# dev. I hate interfaces. Long story: ok, ok, sorry, I got nothing against interface in principle. They could be quite useful :) . It's just that in practice I have seen so many projects with zillion of interfaces with zillion of methods which are only implemented once. Worst, sometimes some of those methods implementation can be derived on the other method and if one would implement the interface twice there would be a lot of copy paste :/ But what really take the cake and I unambiguously despise is the argument that it helps "testability" (using mocks! ho god, mocks, I hate thee so). From what I have seen those people are stickler for "unit test" (as opposed to "integration test") which basically only test the mock that you spend hours writing and make refactoring difficult, but don't really test the application... And it is often white box testing (I know it's implemented this way, that's why I write that test) which contribute to making refactoring a pain. This is worst than waste of time. It also make future developer also waste time.
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
I'm with you on this; it's vary rare that I find a good use for interfaces. more often than not they become must inherit classes with some base functionality, because I absolutely hate redundant code. I think there has been a huge push to use interfaces for dependency injection crap. the downside is it's harder to debug and takes longer to develop. I've been designing software since the mid-90's and I've seen trends come and go (and come back), but in the long run, K.I.S.S. methodology is the thing I go back to: will making this an interface easier or harder for me to figure out in 3 years when I have to revisit this code.
-
In one of the gaming forum that I frequent, they like to post so called "unpopular opinion" thread, and then proceed to say something everybody agrees on... ;P Anyway, while idly driving to work this morning I got stuck by an idea and I am going to try my own take on the unpopular opinion meme. See whether I am also, mistakenly, posting what is in fact a popular opinion! ^_^ So.. here I go. Short story: From a C# dev to another C# dev. I hate interfaces. Long story: ok, ok, sorry, I got nothing against interface in principle. They could be quite useful :) . It's just that in practice I have seen so many projects with zillion of interfaces with zillion of methods which are only implemented once. Worst, sometimes some of those methods implementation can be derived on the other method and if one would implement the interface twice there would be a lot of copy paste :/ But what really take the cake and I unambiguously despise is the argument that it helps "testability" (using mocks! ho god, mocks, I hate thee so). From what I have seen those people are stickler for "unit test" (as opposed to "integration test") which basically only test the mock that you spend hours writing and make refactoring difficult, but don't really test the application... And it is often white box testing (I know it's implemented this way, that's why I write that test) which contribute to making refactoring a pain. This is worst than waste of time. It also make future developer also waste time.
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
I'm not a fan of interfaces either - recently needed to develop plugins for a wide variety of applications - interfaces by their very own nature are contracts with the originating app - it's like having shackles on a plugin that you want to freely distribute - the app shouldn't know anything about a plugin - its the plugin that needs to know about the app's eco-system
Danno
-
In one of the gaming forum that I frequent, they like to post so called "unpopular opinion" thread, and then proceed to say something everybody agrees on... ;P Anyway, while idly driving to work this morning I got stuck by an idea and I am going to try my own take on the unpopular opinion meme. See whether I am also, mistakenly, posting what is in fact a popular opinion! ^_^ So.. here I go. Short story: From a C# dev to another C# dev. I hate interfaces. Long story: ok, ok, sorry, I got nothing against interface in principle. They could be quite useful :) . It's just that in practice I have seen so many projects with zillion of interfaces with zillion of methods which are only implemented once. Worst, sometimes some of those methods implementation can be derived on the other method and if one would implement the interface twice there would be a lot of copy paste :/ But what really take the cake and I unambiguously despise is the argument that it helps "testability" (using mocks! ho god, mocks, I hate thee so). From what I have seen those people are stickler for "unit test" (as opposed to "integration test") which basically only test the mock that you spend hours writing and make refactoring difficult, but don't really test the application... And it is often white box testing (I know it's implemented this way, that's why I write that test) which contribute to making refactoring a pain. This is worst than waste of time. It also make future developer also waste time.
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
Would it be an alternative to switch to DDD - Documentation Driven Development, a sibling of TDD, Test Driven Development, but even before you write the tests, which by TDD is before you write the code, you write the Documentation! Once you have documented all the externally visible method signatures (as well as the implementation architecture, data structures etc.) and then written tests bases on these, then the need for declaring a compileable interface definition is significantly reduced. It won't take you any more resources to start out with the documentation, instead of delaying it until the coding is complete. Quite to the contrary: Good documentation may help speed up coding, when you know where everything fits into The Big Picture. (I take for granted that you do write proper documentation of the system you create.) (And then I will return to doing the last checks of the documentation of my new hobby project, so that I may start coding it tomorrow.)
-
I'm with you on this; it's vary rare that I find a good use for interfaces. more often than not they become must inherit classes with some base functionality, because I absolutely hate redundant code. I think there has been a huge push to use interfaces for dependency injection crap. the downside is it's harder to debug and takes longer to develop. I've been designing software since the mid-90's and I've seen trends come and go (and come back), but in the long run, K.I.S.S. methodology is the thing I go back to: will making this an interface easier or harder for me to figure out in 3 years when I have to revisit this code.
Matt McGuire wrote:
I think there has been a huge push to use interfaces for dependency injection crap. the downside is it's harder to debug and takes longer to develop.
:thumbsup: So true. I mean DI can do some amazing things, but man when you go to debug things it just slow you down so much.
-
Would it be an alternative to switch to DDD - Documentation Driven Development, a sibling of TDD, Test Driven Development, but even before you write the tests, which by TDD is before you write the code, you write the Documentation! Once you have documented all the externally visible method signatures (as well as the implementation architecture, data structures etc.) and then written tests bases on these, then the need for declaring a compileable interface definition is significantly reduced. It won't take you any more resources to start out with the documentation, instead of delaying it until the coding is complete. Quite to the contrary: Good documentation may help speed up coding, when you know where everything fits into The Big Picture. (I take for granted that you do write proper documentation of the system you create.) (And then I will return to doing the last checks of the documentation of my new hobby project, so that I may start coding it tomorrow.)
Documentation is good to have before implementing the feature. Having everything spelled out beforehand is useful for the product owner, tester, and developer. It gives a contract of what to expect. I did this once at a company I worked for. The product owner gave us a set of requirements for a feature. We, the developers would flesh it out into a specification, including the UI, how the UI worked (buttons, sliders, inputs, screen layout, tabs, etc.), underlying algorithms, workflows (user input, processing, output, formatting), file storage formats, etc. This would be kept and later, parts would become user documents, functional documents, and technical documents. The downside to this is that in future releases, when we needed to change the features, these documents would need updating. Usually, more work than we we first created them.
-
Documentation is good to have before implementing the feature. Having everything spelled out beforehand is useful for the product owner, tester, and developer. It gives a contract of what to expect. I did this once at a company I worked for. The product owner gave us a set of requirements for a feature. We, the developers would flesh it out into a specification, including the UI, how the UI worked (buttons, sliders, inputs, screen layout, tabs, etc.), underlying algorithms, workflows (user input, processing, output, formatting), file storage formats, etc. This would be kept and later, parts would become user documents, functional documents, and technical documents. The downside to this is that in future releases, when we needed to change the features, these documents would need updating. Usually, more work than we we first created them.
In the late 1960s, a Norwegian research institute build a prototype for a 16-bit mini - "mini" in those days meaning a full height 19" rack. Around 1971, one grand old company was going to commercialize this design. As always, they had all the documentation printed (500 copies) before the real production was started. Then it was discovered that the guys doing the documentation had been making a couple of errors: For the shift instructions, they had mixed up the bit selecting rotational shift with the don't care bit. And the description of address calculation where the base register (i.e. stack frame pointer) was involved was incorrect. But the documentation was already made, the machines were not. So rather than having to revise 500 copies of documentation, they decided to rather build the machine to behave the way the documentation described it. This is even more crazy considering that two companies were invited to commercialize the design. The other company (a small startup company where they hardly knew the meaning of the word 'documentation') copied the prototype design. So there you had two Norwegian-built machines, with identical instruction set except for rotational shift and identical addressing mechanisms except for stack relative addressing. Both machine series survived for quite a few years, but I never saw a single piece of software that was made to run on both machines. No common compiler with a switch to select either the "KV" or "ND" CPU variant. They ended up in completely non-overlapping market segments, rather than the intention of establishing a solid Norwegian computer industry with two manufacturers sharing architecture and design resources. Thanks to a tech writer who didn't understand the things he was documenting.
-
In one of the gaming forum that I frequent, they like to post so called "unpopular opinion" thread, and then proceed to say something everybody agrees on... ;P Anyway, while idly driving to work this morning I got stuck by an idea and I am going to try my own take on the unpopular opinion meme. See whether I am also, mistakenly, posting what is in fact a popular opinion! ^_^ So.. here I go. Short story: From a C# dev to another C# dev. I hate interfaces. Long story: ok, ok, sorry, I got nothing against interface in principle. They could be quite useful :) . It's just that in practice I have seen so many projects with zillion of interfaces with zillion of methods which are only implemented once. Worst, sometimes some of those methods implementation can be derived on the other method and if one would implement the interface twice there would be a lot of copy paste :/ But what really take the cake and I unambiguously despise is the argument that it helps "testability" (using mocks! ho god, mocks, I hate thee so). From what I have seen those people are stickler for "unit test" (as opposed to "integration test") which basically only test the mock that you spend hours writing and make refactoring difficult, but don't really test the application... And it is often white box testing (I know it's implemented this way, that's why I write that test) which contribute to making refactoring a pain. This is worst than waste of time. It also make future developer also waste time.
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
The big problem is that the interface seems to NEVER live in the correct place. The interface should be either in the project of the consumer (for true Inversion of Control), or a shared project such that it could be consumed by multiple front ends. All too often a class is written than interface is abstracted which is to say the horse is pushing the cart.
-
Super Lloyd wrote:
I think there is a project settings to use them with .NET 4.7.2
There isn't. You can enable C# 8 features in a .NET Framework project, so long as you're using a recent version of VS2019. But that doesn't mean everything will work. Default interface members required changes to the runtime, which were not back-ported to .NET Framework. They will only work with .NET Core (including .NET 5 when it arrives). C# 8.0 and .NET Standard 2.0 - Doing Unsupported Things[^]
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
