Watch, Follow, &
Connect with Us

For forums, blogs and more please visit our
Developer Tools Community.


Welcome, Guest
Guest Settings
Help

Thread: Virtual Method Clarification


This question is answered. Helpful answers available: 2. Correct answers available: 1.


Permlink Replies: 2 - Last Post: Nov 27, 2014 2:10 PM Last Post By: tim crouse
tim crouse

Posts: 83
Registered: 2/11/02
Virtual Method Clarification  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Nov 27, 2014 8:00 AM
It simple terms:

Is a virtual method a child class that has a method named the same as a method in the parent class in which case you add the keyword virtual to the parent method and the keyword override to the child class method?

Is it basically a technique to allow the same method name to be used in multiple instances?

Thanks
Tim C.
Peter Below

Posts: 1,227
Registered: 12/16/99
Re: Virtual Method Clarification  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Nov 27, 2014 10:54 AM   in response to: tim crouse in response to: tim crouse
tim crouse wrote:

It simple terms:

Is a virtual method a child class that has a method named the same as
a method in the parent class in which case you add the keyword
virtual to the parent method and the keyword override to the child
class method?

Is it basically a technique to allow the same method name to be used
in multiple instances?

No. A child class can have methods that have the same name as a method
in the parent class, even without the virtual and override keywords.
What virtual methods give you is a feature called polymorphism in
object oriented programming. Consider this set of classes:

type
TClassA = class(TObject)
public
procedure DoSomething; virtual;
end;
TClassB = class(TClassA)
public
procedure DoSomething; override;
end;
TClassC = class(TClassB)
public
procedure DoSomething; override;
end;

If you have a variable

var
aObj: TClassA;

you can assign an instance of TClassA, TClassB, or TClassC to it. Since
each instance of TClassB and TClassC inherits the complete behaviour of
TClassA this is allowed by the Delphi compatibility rules. Now consider
this:

aObj := GetAnObject;

where

function GetAnObject: TClassA;

can return an instance of any of the three classes mentioned above,
depending on some inner logic that is not of interest at the moment.
What will

aObj.DoSomething;

do then? If aObj refers to an instance of TClassC it will call
TClassC.DoSomething, if a Obj refers to an instance of TClassB it will
call TClassB.DoSomething, and if it really has a TClassA it will call
TClassA.DoSomething. That is polymorphism: the method called is
determined by the actual class of the object referenced by the
variable, not by the type of the variable.

If you remove the virtual/override modifiers from the declarations
above (making the methods static) aObj.DoSomething would always call
TClassA.DoSomething, even if the object is in fact an instance of
TClassB or C. For static methods the type of the variable determines
what method gets called if you have methods with the same name in
several classes in a hierarchy. The compiler issues a warning in this
scenario, but the code will compile and run.


--
Peter Below (TeamB)

tim crouse

Posts: 83
Registered: 2/11/02
Re: Virtual Method Clarification  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Nov 27, 2014 2:10 PM   in response to: Peter Below in response to: Peter Below
Thank You
Very good explanation

Peter Below wrote:
tim crouse wrote:

It simple terms:

Is a virtual method a child class that has a method named the same as
a method in the parent class in which case you add the keyword
virtual to the parent method and the keyword override to the child
class method?

Is it basically a technique to allow the same method name to be used
in multiple instances?

No. A child class can have methods that have the same name as a method
in the parent class, even without the virtual and override keywords.
What virtual methods give you is a feature called polymorphism in
object oriented programming. Consider this set of classes:

type
TClassA = class(TObject)
public
procedure DoSomething; virtual;
end;
TClassB = class(TClassA)
public
procedure DoSomething; override;
end;
TClassC = class(TClassB)
public
procedure DoSomething; override;
end;

If you have a variable

var
aObj: TClassA;

you can assign an instance of TClassA, TClassB, or TClassC to it. Since
each instance of TClassB and TClassC inherits the complete behaviour of
TClassA this is allowed by the Delphi compatibility rules. Now consider
this:

aObj := GetAnObject;

where

function GetAnObject: TClassA;

can return an instance of any of the three classes mentioned above,
depending on some inner logic that is not of interest at the moment.
What will

aObj.DoSomething;

do then? If aObj refers to an instance of TClassC it will call
TClassC.DoSomething, if a Obj refers to an instance of TClassB it will
call TClassB.DoSomething, and if it really has a TClassA it will call
TClassA.DoSomething. That is polymorphism: the method called is
determined by the actual class of the object referenced by the
variable, not by the type of the variable.

If you remove the virtual/override modifiers from the declarations
above (making the methods static) aObj.DoSomething would always call
TClassA.DoSomething, even if the object is in fact an instance of
TClassB or C. For static methods the type of the variable determines
what method gets called if you have methods with the same name in
several classes in a hierarchy. The compiler issues a warning in this
scenario, but the code will compile and run.


--
Peter Below (TeamB)

Legend
Helpful Answer (5 pts)
Correct Answer (10 pts)

Server Response from: ETNAJIVE02