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.
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!
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.