ok to use base. when I don't have to?

  • Thread starter Thread starter Daniel Billingsley
  • Start date Start date
D

Daniel Billingsley

I understand the conditions where you have to use base., but does it make
any sense to use it elsewhere to make clear to the reader that the method or
property you refer to comes from the base class? Or, would you find such
code insulting or clutter since you're smart enough to see that the class is
inherited?
 
Daniel Billingsley said:
I understand the conditions where you have to use base., but does it make
any sense to use it elsewhere to make clear to the reader that the method or
property you refer to comes from the base class? Or, would you find such
code insulting or clutter since you're smart enough to see that the class is
inherited?
Click to expand...
I would suggest against it, if for no reason other than during development
and design you would lock yourself into using a non-virtual method or
property. In the case of a virtual member you would circumvent your
polymorphism and call the base class specifically.
Use it only when you *need* to call the base class, not whenver you are
calling an inherited method
 
I understand the conditions where you have to use base., but does it make
any sense to use it elsewhere to make clear to the reader that the method or
property you refer to comes from the base class? Or, would you find such
code insulting or clutter since you're smart enough to see that the class is
inherited?
Click to expand...

I would say 'no it doesn't make sense to use it elsewhere'. Mainly for
versioning issues, if the method in the base class is non virtual, simply
calling the method allows for the method to be made virtual and overridden
in the future without having to remember 'oh yeh, I need to change that base
call'. IMHO in a OO world you don't need to know whether the method is being
called in a base class or not unless you *really* need to know (ie. you want
to call the base implementation even though you have an overridden version).

n!
 
Hi Daniel,

Thank you for posting in the community!

Based on my understanding, you want to know the difference between *use* or
*not use* base keyword to invoke method in C#.

=========================================================
Actually, if you explicit use base keyword, it means that you want to
invoke the BASE class's method. While "not use" the base keyword, you just
invoke your class's method, which may inherited from your BASE class.

So, the difference may expose using polymorphism, below is the sample code:

class A
{
public virtual void F() { Console.WriteLine("A.F"); }
}

class B: A
{
static void Main()
{
B b=new C();
b.test();
}

public void test()
{
base.F();
F();
}
public override void F() { Console.WriteLine("B.F"); }
}

class C: B
{
public override void F() { Console.WriteLine("C.F"); }
}

The output will generate:
A.F
C.F

So I think you have seen the difference, *not use* base keyword will lead
to the polymorphism, while *use* it will lead to explicit invoke base class
method.

=======================================================
Thank you for your patience and cooperation. If you have any questions or
concerns, please feel free to post it in the group. I am standing by to be
of assistance.
Have a nice day!!

Best regards,
Jeffrey Tan
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.
 
Hi Daniel,

Does my reply make sense to you?

If you still have anything unclear, please feel free to post, I will help
you.

Best regards,
Jeffrey Tan
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.
 
Oh, thanks very much for your feedback, Daniel.

I am glad to hear your feedback that it makes sense :-)

If you have any further concern, please feel free to post, we will help you.

Best regards,
Jeffrey Tan
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.
 
Back
Top