Docs: Deadly Diamond of Death?

Created on 17 May 2019  Â·  4Comments  Â·  Source: dotnet/docs

So, this seems to introduce the DDOD, which is potentially an extremely bad idea, and it's important that developers be able to opt out of this as necessary.

Let's say I have to access both Oracle and Sql Server databases, and I have a class "DbQuery" that implements IOracleQuery and ISqlQuery.

That's all well and good, I've implemented both interfaces, I've used explicit implementation where necessary for both.

Then I write my own method, not implementing an interface, called "FreeMem". Who knows why, but I do.

Now, those that write IOracleQuery and ISqlQuery decide "Hey, we need to free up memory on occasion, let's make a method called "FreeMem". And they both choose the exact same method signature, and entirely different implementations.

Now, let's say I pass a DbQuery into an object that calls IOracleQuery. What happens?

Does it:
A) Call the DbQuery implementation of FreeMem?
B) Call the IOracleQuery implementation of FreeMem?

And let's say I assign a DbQuery object to a dynamic variable and call FreeMem. Do all three get called? One of them?

If the assembly with ISqlQuery is passed my DbQuery, and it treats it as dynamic, does it know which on to call?


Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

Area - C# Guide .NET Core 3.0 P1

Most helpful comment

Your own method will be called, as it implements both/either interface method, as it always has.
If you didn't have an implementation of the method, IOracleQuery.FreeMem would be called if the parameter that is used to call FreeMem is of type IOarcleQuery.

There is a GIGANTIC difference why there is no DDOD problem with default interface methods compared to C++: they are not inherited.
If you have a class C that implements two interfaces A and B and both have a method with a default body M, then your class C does NOT HAVE a method M, because it does not inherit it – just like with explicit interface implementation, which has been around for years.
You'll need to cast your C class to either A or B to use any of their M methods – and thus there is no ambiguity which will be called either.

All 4 comments

@TheOneTrueTrench Yes, that's a risk.

I'll be filling in a full plan for scenarios I need to cover with respect to default interface members. This is an area that I will be addressing. I'll add this issue to the plan.

Your own method will be called, as it implements both/either interface method, as it always has.
If you didn't have an implementation of the method, IOracleQuery.FreeMem would be called if the parameter that is used to call FreeMem is of type IOarcleQuery.

There is a GIGANTIC difference why there is no DDOD problem with default interface methods compared to C++: they are not inherited.
If you have a class C that implements two interfaces A and B and both have a method with a default body M, then your class C does NOT HAVE a method M, because it does not inherit it – just like with explicit interface implementation, which has been around for years.
You'll need to cast your C class to either A or B to use any of their M methods – and thus there is no ambiguity which will be called either.

To clarify: If class C implements method M, you can call C.M of course. But then there is no DDOD either, since that implementation will be used, regardless of whether a variable is of type C, A, or B.

@EnCey is correct that the DDOD issue doesn't happen here. But, the truth is a bit more complicated.

By default, an implementation in an interface is virtual. That modifier isn't necessary. In that case, the class method overrides the interface method.

However, the interface could declare a method sealed. Then, the method is not virtual. In those cases, calling it through an object whose static type is the interface while resolve to the interface method. Calling it on an object of type dynamic resolves to the method declared in the class.

I'll cover this in the context of #12488 But, I'm leaving both issues open because they are not quite duplicates.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

Manoj-Prabhakaran picture Manoj-Prabhakaran  Â·  3Comments

LJ9999 picture LJ9999  Â·  3Comments

tswett picture tswett  Â·  3Comments

FrancescoBonizzi picture FrancescoBonizzi  Â·  3Comments

sdmaclea picture sdmaclea  Â·  3Comments