So recently I've read an article about how the C# 8.0 interfaces changes are bad. I think it's worth reading for yourself, but for the majority of ...
For further actions, you may consider blocking this person and/or reporting abuse
So the old monolith code used to prepend "[error]" in its own so you've added new methods and you have to change the consuming code so that it uses them instead. If you have to update consuming code anyway, why not make a breaking change in the interface instead and do it properly?
The interface breaking implementation does not break consuming code.
What the default method brings is the ability for consuming code to use the new methods without the need to update the logging library, only the logging library contract. But this gets into layers of control and ownership.
Because you don't want to break the existing consuming, and most importantly the implementing code.
You didn't break it on paper, i.e. it's binary-compatible, but not semantically compatible, since you still have to update existing code to use the new API correctly.
I agree, that's misunderstandable on my end. The point is that you can use the new API. Using it doesn't break the old implementation
It seems to me that the both examples can be solved with extension methods. I don't like any of the solutions, though, and I may prefer yours. Probably DI solves everything with none of the issues of both.
What I dislike about IDIs is that interfaces will now come with extra dependencies for the code within. And having optional methods in an interface will bring the huge interfaces back from the hell they were thrown in, only easier to use.
An extension method cannot save warnings to another database table for one implementation and to another file for another, etc.
That said, I think with time best practices will be known over time.
Depending on what extension method class you are referencing, I guess. Never tried having different extension classes with the same signature, though. As I said, it would be ugly.
However, if you first refactor any codebase to use dependency injection, replacing one implementation with another becomes infinitely easy, not to mention testable, but it is a great step to make and many old code doesn't warrant that much effort.
My fear is that there will again be huge 500+ method interfaces and their reason d'etre will be "well, override only what you actually need". There is something inherently evil in interfaces with optional members, like a contract with a fine print, or one of those checkbox menus for marketing :)
I agree, I have also thought about the possibility. I'm the beginning we had a similar problem with extension methods which had stuff like
int.GetElementFromProductsTable()(of course a very hyperbolic example).After people had understood how to use them correctly, extension methods became really useful and liked, but before many (and some still to this Date) habe believed they are cancer for C#.
I think default interface implementations will make a similar journey!
I think you'll need explain how interface updates wouldn't be involved in a dependency injection.
Not saying interfaces are required for DI but usually they are promoted with it.
Default implementations for C# is a good compromise, as you say, for providing traits/multiple inheritance in a sensible manner.
There's some other nice features in C# 8.0 - I use a lot of different languages and rate C# pretty high up on the list of ones I prefer to use. Interesting to see C# 8.0 fixing nullability properly, but in a backwards compatible way - I think any language from now on should do this right, right from the start though.
I've not seen (though it may be a thing) Abstract Type Members in C# - a very useful feature, particularly with traits, something I miss on occasion in languages that don't have it.
I feel like this is something that's gonna be abused. Definitely a good feature to know but that is with proper knowledge of SOLID and other concepts.
Good write up btw
I agree with you. This opens a few areas that could be abused, but I think it's worth it. We probablyshould not teach this to new programmers before SOLID.
Thank you for your answer! I appreciate it!
DII would be really great for using with struct's, but until there's no solution to avoid boxing it's kinda useless. Imo.