Re: Delegates VS interfaces - some confusion

On Sun, 18 Jan 2009 12:31:48 -0800, <beginwithl@xxxxxxxxx> wrote:

I apologize for replying so late, but I was more or less absent for
the last couple of days. Hopefully, it's not too late!

I think as long as you quote the relevant text to which you're replying, it's never too late. :)

[...]
a) I assume your argument with regards as to why interface containing
three methods ( A, B and C ) is not relevant in this debate is due to
polymorphism, meaning if we want to implement polymorphic behavior for
a given type, then we need to call all three methods with same code?

No, the reason that an interface with three methods is not relevant is that a three-method interface is different from the single-method characteristic of a delegate. That is, with a three-method interface, any code with a reference to an implementor of that interface has access to all three methods. With a delegate, the code creating the delegate decides which method is accessible, and only that method is accessible.

b) But if we add another level of abstraction ( the way you did with
wrapping delegates inside ‘CurrentDelegate’ property ), then we can
decide at runtime ( via ‘callAppropriateMethod()’ ��see below for the
code ) which of the three methods to call?!

Delegates allow that, yes. Interfaces don't, not really.

[...]
a) So in essence the main difference is that with interfaces we must
know at compile time what method will be called for a given type, but
with delegates we are able to decide at run time what method of a
given type to call?
Or to put it differently: while with interfaces it is decided at run
time the method of which type will be run, delegates on the other hand
enable us to decide at run time which method of given type will be
run?

Correct. With interfaces, you can select what method to call at run-time as well, but _only_ by changing the implementor of the interface that you're using. With delegates, a single type can provide multiple implementations for the same delegate.

Of course, in practice, for a given delegate, a given type is usually only going to provide just one implementation. Delegates are often just used as a sort of short-hand for producing the same behavior one could by implementing single-method interfaces. For example, the second example I gave could be implemented with interfaces like this:

interface IA
{
void Method1();
}

class A
{
class AA : IA
{
private A _a;

public AA(A a)
{
_a = a;
}

public Method1()
{
_a.MethodA();
}
}

class AB : IA
{
private A _a;

public AB(A a)
{
_a = a;
}

public Method1()
{
_a.MethodB();
}
}

class AC : IA
{
private A _a;

public AC(A a)
{
_a = a;
}

public Method1()
{
_a.MethodC();
}
}

public IA CurrentDelegate
{
get
{
switch (DateTime.Now.DayOfWeek)
{
case DayOfWeek.Monday:
return new AA(this);
case DayOfWeek.Wednesday:
return new AB(this);
default:
return new AC(this);
}
}
}

private void MethodA() { Console.WriteLine("MethodA"); }
private void MethodB() { Console.WriteLine("MethodB"); }
private void MethodC() { Console.WriteLine("MethodC"); }
}

But, as you can see, that's a LOT more verbose than just using a delegate.

BTW - For the sake of simplicity I will call polymorphic behavior
with regards to deciding at run time the method of which type to call
the ‘class level polymorphism’, while I will call the polymorphic
behavior with regards to deciding at run time which method of a given
type to call ‘member level polymorphism’

b) And problem with interfaces is that there is no way to create at
run time calls O.A() or O.C() or O.B(); thus there is no way to
implement members level polymorphism?

No way? That's not exactly true. After all, the implementor of the interface could itself do things conditionally, or with a delegate internally. But at the outer-most level of the implementor, yes..."members level polymorphism" isn't possible.

c) But if your code implementing delegates allows us to decide at run
time what method of given type to call, then why couldn’t the
following code also do the same with interfaces:

interface IA
{
void callAppropriateMethod( some_parameter_list)
void MethodA();
void MethodB();
void MethodC();
}

Well, right here is the problem. You have declared an interface with _four_ different methods, when all you care about is one. The user of this interface could override the intended behavior simply by calling one of the last three methods directly.

This particular interface also has the problem that it knows too much about the implementation. I realize it's just for your example, but assuming any real-world code that looked anything like that, I would call for a redesign of the interface so that the interface didn't leak implementation details like that.

[...]
Ah, so if we want to specify at run time which comparison algorithm to
run ( assuming an object of given type offers various comparison
algorithms ) and if we at the same time want that the same piece of
code will be able to call the appropriate algorithm, then we basically
want to implement ‘member level polymorphism’, which delegates offer
but not interfaces?

Delegates offer it in a much more concise way, yes. Of course, .NET offers the IComparer interface as a way to provide interface-based ways to provide alternate comparisons. It's not an either/or thing.

One final question: - Interfaces enable dynamic dispatch ( a call to a
method is resolved at run time ) only with virtual instance members,
while delegates enable dynamic dispatch for static members also?

Yes...you can assign static methods to delegates, but interfaces must be instance methods.

Pete
.

Relevant Pages

  • Re: Delegates VS interfaces - some confusion
    ... the reason that an interface with three methods is not relevant is   ... implementor) having a direct access to all three methods? ... delegates) due to security reasons, ... giving us member level polymorphism?! ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Interfaces and Events
    ... you have the queue as the focus point. ... William Stacey [MVP] ... Instead of using delegates and events, ...
    (microsoft.public.dotnet.languages.csharp)
  • RE: Delegates and Event to replace with Interface?
    ... Regards ... i can replace the interface with delegates and events as shown on my previous example. ... > int funcB(); ...
    (microsoft.public.dotnet.languages.csharp)
  • RE: Delegates and Event to replace with Interface?
    ... i can replace the interface with delegates ... > interface IChildA ... > int funcB(); ... > After look into your article, is it possible to replace interfaces into delegates. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Delegates VS interfaces - some confusion
    ... an interface with three methods isn't exhibiting polymorphism. ... Uhm, I do understand that delegates enable member level polymorphism, ... Thus delegate types offer us member level polymorphism, ... private void MethodA() ...
    (microsoft.public.dotnet.languages.csharp)
Loading