Re: Delegates VS interfaces - some confusion

hi

I've already taken too much of your time, so I will do my best to wrap
it up as quickly as possible

On Jan 19, 2:07 am, "Peter Duniho" <NpOeStPe...@xxxxxxxxxxxxxxxx>
wrote:
On Sun, 18 Jan 2009 12:31:48 -0800, <beginwi...@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.


a) By accessible you mean directly accessible by an outside code?
So only reason for our interface ( one having three methods ) being
irrelevant is because of outside code ( with a reference to
implementor ) having a direct access to all three methods?

b) And that is bad coding ( in the context of Interfaces VS
delegates ) due to security reasons, lack of encapsulation or…?

c) Is that the sole reason? But to me at least, one major benefit the
delegate offered ( compared to three method interface ) was the
ability to implement polymorphic behavior for a given type --> thus
giving us member level polymorphism?!



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"); }
     }


I know the above code is a lot more verbose compared to delegate
example, but doesn’t the above code allow us to decide at run time
what method to call – thus compiler doesn’t know what method will be
called for a given type, instead the method to call is resolved at run
time?
If that is the case, then couldn’t we argue that with interfaces too
the decision of what method ( algorithm ) to call can be decided at
run time ( via correct implementation ) – granted, they don’t offer us
member level polymorphism ( at least at the most outer level ), the
code is more verbose …?!


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.


So it all comes down to accessibility of the interface methods?

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.

Could you elaborate a bit on that? Many interfaces define several
members, so why is mine too telling?


[...]
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

So it all boils down to this ( I realize I’m being very repetitive in
this post … sorry about that ) :
if we want to implement several methods, where all represent similar
behavior and thus we will always have to choose between them
( depending on some condition ), then we should implement delegates
for the simple fact that that way users can’t call methods directly
( assuming we declare methods as private ) and alter the behavior,
while due to public nature of interfaces, that isn’t possible or it
is, but at the expense of code getting too verbose ?



BTW – Base class library has numerous well known interfaces defined
( like IEnumerable, IComparable ). It is common knowledge that if one
implements a well known interface, some already existing code ( like
foreach statement, or some special classes ) will be able to do some
operations on a class implementing the interface.

Is there also something similar with delegates, in a sense that there
exists some well known delegate, with which if you register your
methods, some special code will do some operation on a class that
registered event handlers with a delegate instance … ?


cheers mate
.

Relevant Pages

  • 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 VS interfaces - some confusion
    ... 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. ... wrapping delegates inside ‘CurrentDelegate’ property), ... private void MethodA() ...
    (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: Help with this sample
    ... polymorphism, although it may be implementing an interface, which is one way ... Events and delegates cannot be used to implement ...
    (microsoft.public.dotnet.languages.csharp)