By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,476 Members | 889 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,476 IT Pros & Developers. It's quick & easy.

Confusion about interface

P: n/a
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
ISynchronizeInvoke.Invoke.
Why?

Thanks in advance
Nov 21 '05 #1
Share this Question
Share on Google+
4 Replies


P: n/a
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 ISynchronizeInvoke 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(ByVal ByHowMuch As Short)
Sub Decelerate(ByVal ByHowMuch As Short)
End Interface

Public Class Car
Implements Automobile

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

Public Property CurrentGear() As Integer Implements Automobile.CurrentGear
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(ByVal ByHowMuch As Short) Implements
Automobile.Decelerate
'Now, you decide exactly how to make this happen
End Sub
End Class
-Scott


"Rulin Hong" <Ru*******@discussions.microsoft.com> wrote in message
news:7E**********************************@microsof t.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
ISynchronizeInvoke.Invoke.
Why?

Thanks in advance

Nov 21 '05 #2

P: n/a
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 IPostBackEventHandler
' 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 IPostBackEventHandler that raises change events.
Public Sub RaisePostBackEvent(eventArgument As String) Implements
IPostBackEventHandler.RaisePostBackEvent
OnClick(EventArgs.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 IPostBackEventHandler.RaisePostBackEvent.
There is none of code about how to postback. In other words, I guess .NET
must have something behind IPostBackEventHandler.RaisePostBackEvent.

Nov 21 '05 #3

P: n/a

"Rulin Hong" <Ru*******@discussions.microsoft.com> wrote in message
news:5C**********************************@microsof t.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 IPostBackEventHandler
' 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 IPostBackEventHandler that raises change events.
Public Sub RaisePostBackEvent(eventArgument As String) Implements
IPostBackEventHandler.RaisePostBackEvent
OnClick(EventArgs.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 IPostBackEventHandler.RaisePostBackEvent.
There is none of code about how to postback. In other words, I guess .NET
must have something behind IPostBackEventHandler.RaisePostBackEvent.


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.CalculateArea
' 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

Nov 21 '05 #4

P: n/a
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*******@discussions.microsoft.com> wrote in message
news:5C**********************************@microsof t.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 IPostBackEventHandler
' 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 IPostBackEventHandler that raises change events.
Public Sub RaisePostBackEvent(eventArgument As String) Implements
IPostBackEventHandler.RaisePostBackEvent
OnClick(EventArgs.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 IPostBackEventHandler.RaisePostBackEvent.
There is none of code about how to postback. In other words, I guess .NET
must have something behind IPostBackEventHandler.RaisePostBackEvent.

Nov 21 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.