Confusion about interface

[Rulin Hong]

According to OO, interface is just a bunch of definitions, no implementation
at all. It's also true when we write our own code in .NET. But I find every
interface provided by .NET has specific implementation.
For example. Control.Invoke Method Executes a delegate on the thread that
owns the control's underlying window handle because it is implemented
ISynchronizeInv oke.Invoke.
Why?

Thanks in advance

[Scott M.]

An interface is just a container for "rules". These rules may include
method, property, event declarations, etc. but do not include any actual
functional code.

Implementing an interface is an agreement to follow the "rules" specified in
the interface. Any class that implements the ISynchronizeInv oke interface,
for example, must also now implement any of the things defined in that
interface (like an Invoke method). It is up to the class that is
implementing the interface to determine what will actually happen when the
Invoke method is called.

A simplified analogy would be that a car's interface includes having a
steering wheel, a gear shifter and the abilities to accelerate and
decelerate. If you were going to build a car, then you'd need to implement
this standard interface (because obviously a car has to have the previously
mentioned things), BUT it would be up to you (the creator of the car) to
determine exactly what kind of steering wheel and gear shifter you wanted
and it would also be up to you to determine exactly HOW you want to
IMPLEMENT the functionality for accelerating and decelerating.

For example:

Public Interface Automobile
Property CurrentGear() As Integer
Sub Accelerate(ByVa l ByHowMuch As Short)
Sub Decelerate(ByVa l ByHowMuch As Short)
End Interface

Public Class Car
Implements Automobile

Public Sub Accelerate(ByVa l ByHowMuch As Short) Implements
Automobile.Acce lerate
'Now, you decide exactly how to make this happen
End Sub

Public Property CurrentGear() As Integer Implements Automobile.Curr entGear
Get
'Now, you decide exactly how to make this happen
End Get
Set(ByVal Value As Integer)
'Now, you decide exactly how to make this happen
End Set
End Property

Public Sub Decelerate(ByVa l ByHowMuch As Short) Implements
Automobile.Dece lerate
'Now, you decide exactly how to make this happen
End Sub
End Class
-Scott


"Rulin Hong" <Ru*******@disc ussions.microso ft.com> wrote in message
news:7E******** *************** ***********@mic rosoft.com...

According to OO, interface is just a bunch of definitions, no
implementation
at all. It's also true when we write our own code in .NET. But I find
every
interface provided by .NET has specific implementation.
For example. Control.Invoke Method Executes a delegate on the thread that
owns the control's underlying window handle because it is implemented
ISynchronizeInv oke.Invoke.
Why?

Thanks in advance

[Rulin Hong]

Scott M.
I know what you said.

I give you another example, Postback Event of web server control. Here is
the code.

Namespace CustomControls
Public Class MyButton
Inherits Control
Implements IPostBackEventH andler
' Defines the Click event.
Public Event Click As EventHandler

' Invokes delegates registered with the Click event.
Protected Overridable Sub OnClick(e As EventArgs)
RaiseEvent Click(Me, e)
End Sub

' Method of IPostBackEventH andler that raises change events.
Public Sub RaisePostBackEv ent(eventArgume nt As String) Implements
IPostBackEventH andler.RaisePos tBackEvent
OnClick(EventAr gs.Empty)
End Sub

Protected Overrides Sub Render(output As HtmlTextWriter)
output.Write("< INPUT TYPE=submit name=" & Me.UniqueID & _
" Value='Click Me' />")
End Sub
End Class
End Namespace

In this code, we just simply write
Implements IPostBackEventH andler.RaisePos tBackEvent.
There is none of code about how to postback. In other words, I guess .NET
must have something behind IPostBackEventH andler.RaisePos tBackEvent.

[Mythran]

"Rulin Hong" <Ru*******@disc ussions.microso ft.com> wrote in message
news:5C******** *************** ***********@mic rosoft.com...

Scott M.
I know what you said.

I give you another example, Postback Event of web server control. Here is
the code.

Namespace CustomControls
Public Class MyButton
Inherits Control
Implements IPostBackEventH andler
' Defines the Click event.
Public Event Click As EventHandler

' Invokes delegates registered with the Click event.
Protected Overridable Sub OnClick(e As EventArgs)
RaiseEvent Click(Me, e)
End Sub

' Method of IPostBackEventH andler that raises change events.
Public Sub RaisePostBackEv ent(eventArgume nt As String) Implements
IPostBackEventH andler.RaisePos tBackEvent
OnClick(EventAr gs.Empty)
End Sub

Protected Overrides Sub Render(output As HtmlTextWriter)
output.Write("< INPUT TYPE=submit name=" & Me.UniqueID & _
" Value='Click Me' />")
End Sub
End Class
End Namespace

In this code, we just simply write
Implements IPostBackEventH andler.RaisePos tBackEvent.
There is none of code about how to postback. In other words, I guess .NET
must have something behind IPostBackEventH andler.RaisePos tBackEvent.

No. This class "implements " an interface. Therefore, specific
implementation of the interface IS required. The interface definition
itself does NOT contain the code for the methods/properties/et cetera, but
implementing class(es) do...ex:

' The following interface contains no implementation code:
Public Interface IShape
Property Width() As Double

Function CalculateArea() As Double
End Interface

' The following class contains implementation code for the IShape interface
declared above.
Public Class Triangle
Implements IShape

Public Function CalculateArea() As Double _
Implements IShape.Calculat eArea
' Calculate the area of the triangle here.
End Function

Public Property Width() As Double Implements IShape.Width
Get
' Return the width.
End Get
Set(ByVal Value As Double)
' Set the width.
End Set
End Property
End Class

HTH,
Mythran

[Scott M.]

Not quite. The control itself already knows how to raise a PostBack event,
you are just implementing an interface that defines a handler for that
event. What you do or do not put in that handler does not determine if the
control will raise the event in the first place, only your class's ability
to handle that event.
"Rulin Hong" <Ru*******@disc ussions.microso ft.com> wrote in message
news:5C******** *************** ***********@mic rosoft.com...

Scott M.
I know what you said.

I give you another example, Postback Event of web server control. Here is
the code.

Namespace CustomControls
Public Class MyButton
Inherits Control
Implements IPostBackEventH andler
' Defines the Click event.
Public Event Click As EventHandler

' Invokes delegates registered with the Click event.
Protected Overridable Sub OnClick(e As EventArgs)
RaiseEvent Click(Me, e)
End Sub

' Method of IPostBackEventH andler that raises change events.
Public Sub RaisePostBackEv ent(eventArgume nt As String) Implements
IPostBackEventH andler.RaisePos tBackEvent
OnClick(EventAr gs.Empty)
End Sub

Protected Overrides Sub Render(output As HtmlTextWriter)
output.Write("< INPUT TYPE=submit name=" & Me.UniqueID & _
" Value='Click Me' />")
End Sub
End Class
End Namespace

In this code, we just simply write
Implements IPostBackEventH andler.RaisePos tBackEvent.
There is none of code about how to postback. In other words, I guess .NET
must have something behind IPostBackEventH andler.RaisePos tBackEvent.