difference between 'overrides' and 'overloads' in class?

[André]

Hi,

i'm learning working with classes.
In class "classbase1", i defined an overridable function. In the class
"subclass1", i defined the same function with 'Overrides'.
In class "classbase2", i defined the same function and in the class
"subclass2", i defined the same function with 'Overloads'.

Result: i get the same output.

My question is: what's the difference between the two approaches? Is one
better than the other? In which cases?

Thanks
André

Public Class classbase1

Public Overridable Function myfunction() As String
Return "start"
End Function

End Class

Public Class subclass1
Inherits classbase1

Public Overrides Function myfunction() As String
Return "end"
End Function

End Class

-------------------------------------------------

Public Class classbase2

Public Function myfunction() As String
Return "start"
End Function

End Class

Public Class subclass2
Inherits classbase2

Public Overloads Function myfunction() As String
Return "end"
End Function

End Class

[lord.zoltar]

Overloading a procedure is having the same procedure defined multiple
times in a class, but each definition has a different signature
(arguments and return).
Overriding a procedure is redefining a procedure from a parent class,
so that it has the same signature, but different implementation. A
procedure that's been overridden can also be overloaded, I think.
maybe...

[Mike Hofer]

On Mar 15, 4:13 pm, [e-mail] wrote:

Overloading a procedure is having the same procedure defined multiple
times in a class, but each definition has a different signature
(arguments and return).
Overriding a procedure is redefining a procedure from a parent class,
so that it has the same signature, but different implementation. A
procedure that's been overridden can also be overloaded, I think.
maybe...

Lord.zol is correct.

For example:

' This is a base class. It must be inherited.
Public MustInherit Class FooBase

' This class is marked Overridable because we
' want to allow derived classes to redefine
' it's behavior. They don't HAVE to, but they
' can if they need to. If they DO override it,
' their version will be called, not ours.
'
' We also mark it Overridable because we have
' another method with the same name, but that
' version takes a parameter, while this version
' does not.
Public Overloads Overridable Sub Bar()
Debug.WriteLine("FooBase.Bar")
End Sub

Public Overloads Overridable Sub Bar(ByVal value As String)
Debug.WriteLine("FooBase.Bar: " & value)
End Sub

End Class
' This is a derived class, inheriting FooBase.
Public Class Foo
Inherits FooBase

' This method is marked overloads because it has
' the same name, but changes the argument list.
' It would do the same if the return type changed.
'
' The base class's version takes a string. This
' one takes an integer.
Public Overloads Sub Bar(ByVal value As Integer)
Debug.WriteLine("Foo.Bar: " & CStr(value))
End Sub

' This method is marked Overrides because it has
' the same name AND signature as a method in the
' base class, and changes the behavior of that
' method.
'
' It is also marked Overloads because there are
' other methods that have the same name both in
' this class and the base class.
Public Overloads Overrides Sub Bar()
Debug.WriteLine("Foo.Bar")
End Sub

End Sub

Hope this helps!
Mike

[Mike Hofer]

Sorry! Typo! Here's the fixed code!

' This is a base class. It must be inherited.
Public MustInherit Class FooBase

' This class is marked Overridable because we
' want to allow derived classes to redefine
' it's behavior. They don't HAVE to, but they
' can if they need to. If they DO override it,
' their version will be called, not ours.
'
' We also mark it Overloads because we have
' another method with the same name, but that
' version takes a parameter, while this version
' does not.
Public Overloads Overridable Sub Bar()
Debug.WriteLine("FooBase.Bar")
End Sub

Public Overloads Overridable Sub Bar(ByVal value As String)
Debug.WriteLine("FooBase.Bar: " & value)
End Sub

End Class
' This is a derived class, inheriting FooBase.
Public Class Foo
Inherits FooBase

' This method is marked overloads because it has
' the same name, but changes the argument list.
' It would do the same if the return type changed.
'
' The base class's version takes a string. This
' one takes an integer.
Public Overloads Sub Bar(ByVal value As Integer)
Debug.WriteLine("Foo.Bar: " & CStr(value))
End Sub

' This method is marked Overrides because it has
' the same name AND signature as a method in the
' base class, and changes the behavior of that
' method.
'
' It is also marked Overloads because there are
' other methods that have the same name both in
' this class and the base class.
Public Overloads Overrides Sub Bar()
Debug.WriteLine("Foo.Bar")
End Sub

End Sub

[André]

Thanks both for your explanation

"Mike Hofer" <kc********@gmail.comschreef in bericht
news:11**********************@y66g2000hsf.googlegr oups.com...

Sorry! Typo! Here's the fixed code!

' This is a base class. It must be inherited.
Public MustInherit Class FooBase

' This class is marked Overridable because we
' want to allow derived classes to redefine
' it's behavior. They don't HAVE to, but they
' can if they need to. If they DO override it,
' their version will be called, not ours.
'
' We also mark it Overloads because we have
' another method with the same name, but that
' version takes a parameter, while this version
' does not.
Public Overloads Overridable Sub Bar()
Debug.WriteLine("FooBase.Bar")
End Sub

Public Overloads Overridable Sub Bar(ByVal value As String)
Debug.WriteLine("FooBase.Bar: " & value)
End Sub

End Class
' This is a derived class, inheriting FooBase.
Public Class Foo
Inherits FooBase

' This method is marked overloads because it has
' the same name, but changes the argument list.
' It would do the same if the return type changed.
'
' The base class's version takes a string. This
' one takes an integer.
Public Overloads Sub Bar(ByVal value As Integer)
Debug.WriteLine("Foo.Bar: " & CStr(value))
End Sub

' This method is marked Overrides because it has
' the same name AND signature as a method in the
' base class, and changes the behavior of that
' method.
'
' It is also marked Overloads because there are
' other methods that have the same name both in
' this class and the base class.
Public Overloads Overrides Sub Bar()
Debug.WriteLine("Foo.Bar")
End Sub

End Sub

[Branco Medeiros]

André wrote:

i'm learning working with classes.
In class "classbase1", i defined an overridable function. In the class
"subclass1", i defined the same function with 'Overrides'.
In class "classbase2", i defined the same function and in the class
"subclass2", i defined the same function with 'Overloads'.

Result: i get the same output.

My question is: what's the difference between the two approaches? Is one
better than the other? In which cases?

<snip>

The Overloads keyword is there just to make clear your intent to
create a method with the same name of another -- but with a *different
signature*. It's not mandatory unless you use it in one method: then
you must use it in each overload of the same method.

The Overridable/Overrides pair, on the other side, is one of the
cornerstones of OOP. Together with inheritance it allows the so called
polymorphism, where a derived class pass as another (its base class)
but behaves differently.

This is how it works: you declare an "Overridable" method ("Virtual"
in OOP lingo), indicating that the method can be "specilized" by
derived classes. To do this, the derived class defines a method *with
the same signature*, but decorated with the Overrides keyword.

Now, when you call the overriden method in the derived class, nothing
out of the ordinary seems to happen. The magic actually occurs when
your derived class is being used in places where the *base* class is
expected. Then, instead of using the base's implementation, what gets
called is the derived's implementation!

I guess this is easier to show than to describe.

Class Base
'a "virtual" method
Overridable Sub Print(Text As String)
Console.Write(Text.ToLower)
End Sub

'A non-virtual method
Sub SayCheese()
Console.Write("Cheddar!")
End Sub
End Class

Class Derived
Inherits Base
'An override of the ancestor method
Overrides Sub Print(Text As String)
Console.Write("<text>" & Text.ToUpper & "</text>")
End Sub

'a regular method that happens to have
'the same name of one in the ancestor
Sub SayCheese
Console.Write("Gruyere!")
End Sub

'a method specific to the
'derived class
Sub RevealYourself
End Sub

End Class

Dim A As Base '<- "A" is declared as Base

A = New Base
A.SayCheese
'output: Cheddar!

A.Print("Hellow, World")
'output: hello, world

A = New Derived '<-- "A" is "seen" as Base!
A.SayCheese
'output: Cheddar!

A.Print("Hellow, World")
'output: <text>HELLO, WORLD</text>

'Compilation error
'(put here because it's a common mistake
'among newcomers)

A.RevealYourself '<- no, no, no!... "A" is declared as **Base**
HTH.

Regards,

Branco.

PS: Now, try to explain to yourself the meaning of a
"MustOverride" ("Abstract" to OOP purists) method...

[Mike Hofer]

On Mar 16, 10:45 am, "Branco Medeiros" <[e-mail]>
wrote:

André wrote:

i'm learning working with classes.
In class "classbase1", i defined an overridable function. In the class
"subclass1", i defined the same function with 'Overrides'.
In class "classbase2", i defined the same function and in the class
"subclass2", i defined the same function with 'Overloads'.

Result: i get the same output.

My question is: what's the difference between the two approaches? Is one
better than the other? In which cases?

<snip>

The Overloads keyword is there just to make clear your intent to
create a method with the same name of another -- but with a *different
signature*. It's not mandatory unless you use it in one method: then
you must use it in each overload of the same method.

The Overridable/Overrides pair, on the other side, is one of the
cornerstones of OOP. Together with inheritance it allows the so called
polymorphism, where a derived class pass as another (its base class)
but behaves differently.

This is how it works: you declare an "Overridable" method ("Virtual"
in OOP lingo), indicating that the method can be "specilized" by
derived classes. To do this, the derived class defines a method *with
the same signature*, but decorated with the Overrides keyword.

Now, when you call the overriden method in the derived class, nothing
out of the ordinary seems to happen. The magic actually occurs when
your derived class is being used in places where the *base* class is
expected. Then, instead of using the base's implementation, what gets
called is the derived's implementation!

I guess this is easier to show than to describe.

Class Base
'a "virtual" method
Overridable Sub Print(Text As String)
Console.Write(Text.ToLower)
End Sub

'A non-virtual method
Sub SayCheese()
Console.Write("Cheddar!")
End Sub
End Class

Class Derived
Inherits Base
'An override of the ancestor method
Overrides Sub Print(Text As String)
Console.Write("<text>" & Text.ToUpper & "</text>")
End Sub

'a regular method that happens to have
'the same name of one in the ancestor
Sub SayCheese
Console.Write("Gruyere!")
End Sub

'a method specific to the
'derived class
Sub RevealYourself
End Sub

End Class

Dim A As Base '<- "A" is declared as Base

A = New Base
A.SayCheese
'output: Cheddar!

A.Print("Hellow, World")
'output: hello, world

A = New Derived '<-- "A" is "seen" as Base!
A.SayCheese
'output: Cheddar!

A.Print("Hellow, World")
'output: <text>HELLO, WORLD</text>

'Compilation error
'(put here because it's a common mistake
'among newcomers)

A.RevealYourself '<- no, no, no!... "A" is declared as **Base**

HTH.

Regards,

Branco.

PS: Now, try to explain to yourself the meaning of a
"MustOverride" ("Abstract" to OOP purists) method...

Branco,

I got to thinking about this last night and this morning, wondering if
there was a nifty way we could sum up the difference between the two
key words. Something to help people remember the difference. And I
thought that this might do the trick:

-- Use Overloads when you want to change the arguments or return type
for a method or property, but not the behavior.

-- Use Overrides when you want to keep the same arguments and return
type for a method or property, and change the behavior.

What do you think?

Mike

[Branco Medeiros]

Mike Hofer wrote:

I got to thinking about this last night and this morning, wondering if
there was a nifty way we could sum up the difference between the two
key words. Something to help people remember the difference. And I
thought that this might do the trick:

-- Use Overloads when you want to change the arguments or return type
for a method or property, but not the behavior.

-- Use Overrides when you want to keep the same arguments and return
type for a method or property, and change the behavior.

What do you think?

Hi, Mike!

You're right, that prety much sums up the differences between both
keywords ("to sum up the differences", is there really such
expression?).

If one wants to be really terse he/she may sumarize your definitions
with "Overloads, signature; Overrides, behavior"... =)

Regards,

Branco.

[lord.zoltar]

>
You're right, that prety much sums up the differences between both
keywords ("to sum up the differences", is there really such
expression?).

If one wants to be really terse he/she may sumarize your definitions
with "Overloads, signature; Overrides, behavior"... =)

what about when you want to override an overload, or overload an
override? Or some sort of nested combination? :P

[Mike Hofer]

On Mar 16, 3:57 pm, [e-mail] wrote:

You're right, that prety much sums up the differences between both
keywords ("to sum up the differences", is there really such
expression?).

If one wants to be really terse he/she may sumarize your definitions
with "Overloads, signature; Overrides, behavior"... =)

what about when you want to override an overload, or overload an
override? Or some sort of nested combination? :P

I think my brain just cramped.

=)

Mike

[Cor Ligthert [MVP]]

Andre,

Maybe does this sample gives beside the fine answers you got already help
you to understand it.
In my idea does it as well give an answer if explicite disposing of a label
makes sense.

After that the program is ended. The disposing method of that will be
overriden and shows the text in the messagebox. It is easy to try, only open
a form and paste the code in the not already part in.

(The sample is as short as can be)

Cor

\\\
Public Class Form1
Inherits System.Windows.Forms.Form
#Region " Windows Form Designer generated code "
Private Sub Form1_Load(ByVal sender As System.Object, _
ByVal e As System.EventArgs) Handles MyBase.Load
Dim myLabel As New MyBaseLabel
Me.Controls.Add(myLabel)
End Sub
End Class

Public Class MyBaseLabel
Inherits System.Windows.Forms.TextBox
Protected Overloads Overrides Sub Dispose(ByVal disposing As Boolean)
If disposing Then
MessageBox.Show("The label is disposing")
End If
MyBase.Dispose(disposing)
End Sub
End Class
///

[Branco Medeiros]

in response to this post from lord.zolt:

what about when you want to override an overload, or overload an
override? Or some sort of nested combination? :P

Mike Hofer wrote:

I think my brain just cramped.

=))

The definition you made of the two keywords is completely valid.

Override an overload means, I guess, creating a new method that maps
to one in the base class, when you already have a method with the same
name, but different signature.

Overload an override is, I suppose, creating an alternate signature to
a method that is already an override, i.e., maps to one in the base
class.

Class A
Overridable Sub S()
End Sub
End Class

Class B: Inherits Class A
'the overload
Overloads Sub S(P As Integer)
End Sub

'the override
Overrides Sub S()
End Sub
End Class

If I understood lord.zolt correctly, there's nothing new, here, just
word games... =)

Regards,

Branco.

[André]

Hi all,

thanks again for you explanation

"Cor Ligthert [MVP]" <no************@planet.nlschreef in bericht
news:ei**************@TK2MSFTNGP04.phx.gbl...

Andre,

Maybe does this sample gives beside the fine answers you got already help
you to understand it.
In my idea does it as well give an answer if explicite disposing of a
label makes sense.

After that the program is ended. The disposing method of that will be
overriden and shows the text in the messagebox. It is easy to try, only
open a form and paste the code in the not already part in.

(The sample is as short as can be)

Cor

\\\
Public Class Form1
Inherits System.Windows.Forms.Form
#Region " Windows Form Designer generated code "
Private Sub Form1_Load(ByVal sender As System.Object, _
ByVal e As System.EventArgs) Handles MyBase.Load
Dim myLabel As New MyBaseLabel
Me.Controls.Add(myLabel)
End Sub
End Class

Public Class MyBaseLabel
Inherits System.Windows.Forms.TextBox
Protected Overloads Overrides Sub Dispose(ByVal disposing As Boolean)
If disposing Then
MessageBox.Show("The label is disposing")
End If
MyBase.Dispose(disposing)
End Sub
End Class
///