I am brand new to base classes so please correct me if I am wrong or I should be doing this another way, but I have coded a simple code snippet below that explains what I want to do.
class A : B
{
private int _classId;
public A (int id) : base(id)
{
_classId = id;
}
public string GetString()
{
return "This will eventually be an important string.";
}
}
class B
{
private int _classId;
public B (int id)
{
// here I want to be able to get access to class A's methods
// such as GetString() ...
}
public void SomeMethod()
{
}
}
So what I want to do is allow B to get A's methods.
Reason for doing this?
I don't want to populate the class A because B is going to have a lot of methods so it would be cleaner to keep them in B then just get them from A in other code. Am I doing this wrong? is this not what base classes do? I simply just want to be able to still do this:
A.SomeMethodInB();
Without populating class A with junk and making it cleaner by storing it in class B
Let me summarize your question:
You want a method that is only implemented in a descendant class (A)
You want this method to be available to both the base class (B) and the descendant class (A)
You want the base class to be able to call the descendant class' implementation of the method
This is the original definition of polymorphism (lately people have been using the term much more generally) and is bread-and-butter when it comes to OOP. It is also the hardest area of OOP to grasp for newcomers.
Write a base class with a virtual method
Let us start with the base class. Notice I have changed your example slightly, for a reason I will explain in a moment.
class B
{
virtual protected string GetString()
{
return "I am a B";
}
public void DoSomethingWithGetString()
{
Console.WriteLine(GetString());
}
}
In this example, DoSomethingWithGetString calls GetString. Note that GetString is virtual. This tells the compiler that we don't want to decide where the implementation of GetString is until runtime. This means it can't be bound at compile time: instead, its location is identified by a runtime Virtual Method Table that is set up when the object is created. If this code is running as part of a instance of class B, then it will call class B's implementation of GetString. But if this code was inherited, and is actually being called by some other object that descends from class B, it will call that class' version of GetString. This is called late binding.
Write the descendant class
So now let's write class A:
class A : B
{
protected override GetString()
{
return "I am an A.";
}
}
Because A descends from B, we don't need to implement anything else. If we call A.DoSomethingWithGetString it'll actually call B's implementation because it is inherited.
Execute it
If you run this code
var a = new A();
a.DoSomethingWithGetString(); //Output = "I am an A"
...the following will happen:
An instance of A, which descends from B, is created
The VMT of A is configured so that calls to GetString are sent to A.GetString.
You call A.DoSomethingWithGetString
This call is directed to B's code base, because A doesn't implement it.
The code base in B detects that GetString is a virtual method, and calls it using the VMT.
The VMT points to A's implementation of GetString.
A.GetString is executed.
Thus you have an situation where code in class B is calling code in class A, which is what you asked for.
You can also run it this way:
B b = new A();
b.DoSomethingWithGetString(); //Output = "I am an A"
Thus you have a pointer to a B that says it's an A, because it is using a VMT set up for class A.
But I don't want any implementation in class B
Now, let's say you don't want class B to have any implementation at all for GetString, but you still want to be able to call the implementation in A. There is a way to do this using an abstract virtual method. Simply add the abstract keyword and remove the implementation:
abstract class B
{
abstract protected string GetString(); //Notice no implementation
public void DoSomethingWithGetString()
{
Console.WriteLine(GetString());
}
}
Of course, now you can't use class B by itself, because it requires an implementation of GetString that will only be present in a descendant class. So you can no longer create an instance of B directly; you have to subtype, and use the subtype.
Can't use constructor
Now, you'll notice in my example I removed your constructor calls. There is a reason for this. A constructor should not ever call a method that is defined on a descendant class. The reason: during construction, constructors are called up and down the inheritance hierarchy, starting with the base class and moving down the descendant chain. That means, when you call B's constructor, A's constructor has not been called yet. if A's constructor hasn't run yet, we can't be sure that A has been properly set up yet, and therefore it is a really bad idea to call any of its methods.
There are some workarounds for this, but that is a topic for a different question.
If the method is only defined in Class A, then there is no way to access it through Class B.
If the method exists in both Class A and Class B, then you can use virtual method and override.
Think it is better to use the names BaseClass and DerivedClass in an example. The names A and B are kind of arbitrary. Although A comes before B, the names don't imply the direction of inheritance intended.
class Program
{
static void Main(string[] args)
{
var bc = new BaseClass(3);
var dc = new DerivedClass(5);
Console.WriteLine("Base Class Method A: " + bc.MethodA());
Console.WriteLine("Derived Class Method A: " + dc.MethodA());
Console.WriteLine("Base Class Method B: " + bc.MethodB());
Console.WriteLine("Derived Class Method B: " + dc.MethodB());
Console.ReadLine();
}
}
public class BaseClass {
protected int _classId;
public BaseClass(int classId) {
_classId = classId;
}
public virtual string MethodA() {
return "Method A in base class: " + _classId.ToString();
}
public string MethodB()
{
return "I am a method B in the base class: " + _classId.ToString();
}
}
public class DerivedClass : BaseClass {
public DerivedClass(int classId)
: base(classId)
{
}
public override string MethodA() {
return "Method A in derived class: " + _classId.ToString();
}
}
There are two ways you can go about this. Let me first set out an example.
Here we have the base class that contains a method:
public class Base
{
public void BaseMethod()
{
// Some method.
}
}
Here is the derived class, where we want to call the method:
public class DerivedClass : BaseClass
{
// We want to use BaseMethod() here.
}
In order to call a method from the base class, we use the base keyword.
public class DerivedClass : BaseClass
{
base.BaseMethod();
}
This is fine if you want to just call the base method. However, if we want to change the method and define it with a different function, we have to declare it as virtual in the base class, as so:
public class Base
{
public virtual void BaseMethod()
{
// Some method.
}
}
In the derived class, we can now use the keyword override to override the virtual method of the base class, which redefines it to do something else:
public class DerivedClass : BaseClass
{
public override void BaseMethod()
{
// Some new function.
}
}
Related
I'm overriding some existing codes but try not to touch the existing classes.
I have a base class
public class A {
public virtual void Func() {
do something...
}
}
I have several other classes is accessing it by calling A.Func()
I'm writing an extension class
public class B : A {
public override void Func() {
do something else...
}
}
Without touching the base and those classes calling the base class, is there any way to point the method Func() to the extended class?
I mean when there's a class calling A.Func(), it executes the B.Func() instead A.Func()
But without touching the code from that class nor the A class
An example
public class C {
void SomeOutsideFunc()
{
var a = new A();
a.Func(); //in here, is it possible to execute the extended B class's Func()?
}
}
in above example
class A and class C is forbidden for any modification
class B is an extended class I coded.
right now, I have to make another override to class C to make things working
my issue is there are a lot of C type classes (none of those that I can make any changes)
tks
You can create the object of base class which is pointing to the child class, suppose B.
A objA=new B();
objA.Func();
This will call the function of derived class.
What you're describing is how things already work. Imagine you have these two classes:
public class BaseClass
{
public virtual void WriteSomething()
{
Console.WriteLine("base write something");
}
}
public class DerivedClass : BaseClass
{
public override void WriteSomething()
{
Console.WriteLine("derived write something");
}
}
If you create an instance of BaseClass and call WriteSomething, you get "base write something":
BaseClass instance = new BaseClass();
instance.WriteSomething();
// "base write something" is printed to the console
Likewise, creating an instance of DerivedClass and calling WriteSomething results in "derived write something":
DerivedClass instance = new DerivedClass();
instance.WriteSomething();
// "derived write something" is printed to the console
Even if we assign that instance to a BaseClass variable, we still get "derived write something":
DerivedClass instance = new DerivedClass();
BaseClass instanceAsBaseClass = instance;
instanceAsBaseClass.WriteSomething();
// "derived write something" is printed to the console
So we can clearly then pass this into a method as BaseClass but still use the overriden methods from the derived class:
public static void DoSomeThings(BaseClass instance)
{
instance.WriteSomething();
}
BaseClass instance = new DerivedClass();
DoSomeThings(instance);
// "derived write something" is printed to the console
Note that we haven't changed the DoSomeThings method.
Try it online
What are differences between declaring a method in a base type "virtual" and then overriding it in a child type using the "override" keyword as opposed to simply using the "new" keyword when declaring the matching method in the child type?
I always find things like this more easily understood with pictures:
Again, taking joseph daigle's code,
public class Foo
{
public /*virtual*/ bool DoSomething() { return false; }
}
public class Bar : Foo
{
public /*override or new*/ bool DoSomething() { return true; }
}
If you then call the code like this:
Foo a = new Bar();
a.DoSomething();
NOTE: The important thing is that our object is actually a Bar, but we are storing it in a variable of type Foo (this is similar to casting it)
Then the result will be as follows, depending on whether you used virtual/override or new when declaring your classes.
The "new" keyword doesn't override, it signifies a new method that has nothing to do with the base class method.
public class Foo
{
public bool DoSomething() { return false; }
}
public class Bar : Foo
{
public new bool DoSomething() { return true; }
}
public class Test
{
public static void Main ()
{
Foo test = new Bar ();
Console.WriteLine (test.DoSomething ());
}
}
This prints false, if you used override it would have printed true.
(Base code taken from Joseph Daigle)
So, if you are doing real polymorphism you SHOULD ALWAYS OVERRIDE. The only place where you need to use "new" is when the method is not related in any way to the base class version.
Here's some code to understand the difference in the behavior of virtual and non-virtual methods:
class A
{
public void foo()
{
Console.WriteLine("A::foo()");
}
public virtual void bar()
{
Console.WriteLine("A::bar()");
}
}
class B : A
{
public new void foo()
{
Console.WriteLine("B::foo()");
}
public override void bar()
{
Console.WriteLine("B::bar()");
}
}
class Program
{
static int Main(string[] args)
{
B b = new B();
A a = b;
a.foo(); // Prints A::foo
b.foo(); // Prints B::foo
a.bar(); // Prints B::bar
b.bar(); // Prints B::bar
return 0;
}
}
The new keyword actually creates a completely new member that only exists on that specific type.
For instance
public class Foo
{
public bool DoSomething() { return false; }
}
public class Bar : Foo
{
public new bool DoSomething() { return true; }
}
The method exists on both types. When you use reflection and get the members of type Bar, you will actually find 2 methods called DoSomething() that look exactly the same. By using new you effectively hide the implementation in the base class, so that when classes derive from Bar (in my example) the method call to base.DoSomething() goes to Bar and not Foo.
Beyond just the technical details, I think using virtual/override communicates a lot of semantic information on the design. When you declare a method virtual, you indicate that you expect that implementing classes may want to provide their own, non-default implementations. Omitting this in a base class, likewise, declares the expectation that the default method ought to suffice for all implementing classes. Similarly, one can use abstract declarations to force implementing classes to provide their own implementation. Again, I think this communicates a lot about how the programmer expects the code to be used. If I were writing both the base and implementing classes and found myself using new I'd seriously rethink the decision not to make the method virtual in the parent and declare my intent specifically.
virtual / override tells the compiler that the two methods are related and that in some circumstances when you would think you are calling the first (virtual) method it's actually correct to call the second (overridden) method instead. This is the foundation of polymorphism.
(new SubClass() as BaseClass).VirtualFoo()
Will call the SubClass's overriden VirtualFoo() method.
new tells the compiler that you are adding a method to a derived class with the same name as a method in the base class, but they have no relationship to each other.
(new SubClass() as BaseClass).NewBar()
Will call the BaseClass's NewBar() method, whereas:
(new SubClass()).NewBar()
Will call the SubClass's NewBar() method.
The difference between the override keyword and new keyword is that the former does method overriding and the later does method hiding.
Check out the folllowing links for more information...
MSDN and Other
new keyword is for Hiding. - means you are hiding your method at runtime. Output will be based base class method.
override for overriding. - means you are invoking your derived class method with the reference of base class. Output will be based on derived class method.
My version of explanation comes from using properties to help understand the differences.
override is simple enough, right ? The underlying type overrides the parent's.
new is perhaps the misleading (for me it was). With properties it's easier to understand:
public class Foo
{
public bool GetSomething => false;
}
public class Bar : Foo
{
public new bool GetSomething => true;
}
public static void Main(string[] args)
{
Foo foo = new Bar();
Console.WriteLine(foo.GetSomething);
Bar bar = new Bar();
Console.WriteLine(bar.GetSomething);
}
Using a debugger you can notice that Foo foo has 2 GetSomething properties, as it actually has 2 versions of the property, Foo's and Bar's, and to know which one to use, c# "picks" the property for the current type.
If you wanted to use the Bar's version, you would have used override or use Foo foo instead.
Bar bar has only 1, as it wants completely new behavior for GetSomething.
Not marking a method with anything means: Bind this method using the object's compile type, not runtime type (static binding).
Marking a method with virtual means: Bind this method using the object's runtime type, not compile time type (dynamic binding).
Marking a base class virtual method with override in derived class means: This is the method to be bound using the object's runtime type (dynamic binding).
Marking a base class virtual method with new in derived class means: This is a new method, that has no relation to the one with the same name in the base class and it should be bound using object's compile time type (static binding).
Not marking a base class virtual method in the derived class means: This method is marked as new (static binding).
Marking a method abstract means: This method is virtual, but I will not declare a body for it and its class is also abstract (dynamic binding).
using System;
using System.Text;
namespace OverrideAndNew
{
class Program
{
static void Main(string[] args)
{
BaseClass bc = new BaseClass();
DerivedClass dc = new DerivedClass();
BaseClass bcdc = new DerivedClass();
// The following two calls do what you would expect. They call
// the methods that are defined in BaseClass.
bc.Method1();
bc.Method2();
// Output:
// Base - Method1
// Base - Method2
// The following two calls do what you would expect. They call
// the methods that are defined in DerivedClass.
dc.Method1();
dc.Method2();
// Output:
// Derived - Method1
// Derived - Method2
// The following two calls produce different results, depending
// on whether override (Method1) or new (Method2) is used.
bcdc.Method1();
bcdc.Method2();
// Output:
// Derived - Method1
// Base - Method2
}
}
class BaseClass
{
public virtual void Method1()
{
Console.WriteLine("Base - Method1");
}
public virtual void Method2()
{
Console.WriteLine("Base - Method2");
}
}
class DerivedClass : BaseClass
{
public override void Method1()
{
Console.WriteLine("Derived - Method1");
}
public new void Method2()
{
Console.WriteLine("Derived - Method2");
}
}
}
I have an abstract base class from which I derive two classes. The abstract class has a protected field which is initialized by constructors in the derived classes. Each of the derived classes has two constructors, the first constructor of each class initializes the field and the second constructor modifies the initialization of the first by calling the first constructor. The second constructor of both derived classes are exactly the same but the first constructor is different between the two derived classes. Is there some way to put the second constructor in the base class?
Here is an example to illustrate what I'm trying to say:
public abstract class A {
protected int[] field1;
public void someMethod() {
//somethingsomething
}
}
public class B : A {
public B() {
//body X
//this initializes field1 in some way
}
public B(bool p) : this() {
//body Y
//this initializes field1 in some way + modification
}
}
public class C : A {
public C() {
//body Z
//this initializes field1 in another way
}
public C(bool p) : this() {
//body Y
//this initializes field1 in another way + modification
}
}
What I would like to do, is to find some way so as to not have to repeat body Y twice. I was thinking of putting body Y of B(bool p) and C(bool p) in a constructor in class A as A(bool p), then have B(bool p) and C(bool p) call the base class constructor with : base(bool p) followed by an empty body, but then realized the base class constructor would have to call the derived class constructor.
This sounds stupid to me too. Although I am not sure, it's because I have this feeling that calling something from a derived class from a base class is something that can only be done at run time and there really is no way to check this at compile time. I'm just trying to find a way to follow the DRY principle.
Thanks.
Short answer: no. That would be breaking the object-oriented paradigm, so you wouldn't want to be able to do that anyway. Think about it this way: an abstract base class can be extended by an arbitrary number of classes, but if it was tightly coupled to one of the child classes, how would that impact the other ones?
public class BaseClass {
// Call child class constructor
public BaseClass() : A() { }
}
public class A : BaseClass {
public A() { ... }
}
// How should BaseClass handle this? There is no constructor named "A."
public class B : BaseClass {
public B() { ... }
}
If you want the base class and derived class to share some functionality, you should make it a protected method in the base class. That way, you can call that method from the constructor.
You could also make a constructor on the base class that provides the common functionality and call it from the child class with : base(...).
The only way a base class can trigger a derived behavior is through polymorphism (having a virtual method in B, and overriding it).
But there's some other way that might be much more inuitive in your case. For example:
public class C : A {
public C() {
//body Z
//this initializes field1 in another way
}
public C(bool p) : base(p) {
//this initializes field1 in another way + modification
}
}
Please note that in your example, B's default constructor calls A's default constructor, as well as C's default one calls B's default one.
Lastly, you can also consider having a second constructor in A that receives field1 initial value as a parameter, but it depends if your instructions are order-dependent.
If you precise what your constructors do exactly, I might have a more decisive answer for you.
Sincerely,
I thought I had this nailed, and then I go and look at some source at work and am left wondering why there are so many contradictions in what I read from msdn and what I am seeing in source....
My understanding is that the virtual keyword can be used in method declarations to allow any deriving classes to override it.
The override keyword would then need to be used in the derived class when implementing the superclass' virtual method....
For example:
public abstract class A
{
public virtual string GetName();
}
public class B:A
{
//assume there are some defined properties.
public override string GetName()
{
return FirstName;
}
}
I have a few questions:
1) Is it really necessary to define a method as virtual if it has no implementation? Surely it can just be overwritten in the subclass without the use of virtual and override?
2) If (1) is incorrect, am I right in thinking that every virtual method must be overridden in the subclass using it....
EDIT:
You're right my code will not compile... I want to know why....I uinderstand your answers but then I saw this:
public abstract class RequestHandler<TRequest, TResponse> : RequestHandler, IRequestHandler<TRequest>, IRequestHandler, IDisposable, ITypedRequestHandler
where TRequest : global::Agatha.Common.Request
where TResponse : global::Agatha.Common.Response, new()
{
protected RequestHandler();
public virtual void AfterHandle(TRequest request);
public virtual void BeforeHandle(TRequest request);
public override Response CreateDefaultResponse();
public TResponse CreateTypedResponse();
public override Response Handle(Request request);
public abstract Response Handle(TRequest request);
}
The above doesnt cause the compiler to complain...
Firstly the above code is invalid. A virtual method still has to have a body with a default implementation. to do what you have done above you would need to use the abstract keyaord instead of virtual.
abstract means that there is no method body provided but that any class deriving from it must implement this method (unless it is abstract too).
I think this pretty much answers your questions....
If it has no implementation then it cannot be virtual, it must be abstract. If it has an implementation that just does nothing then that must be implemented.
The whole point of a virtual class is that it has default behaviour so you can choose whether or not to override it. If it were abstract then you would have to override it (unless you were deriving another abstract class).
Is it really necessary to define a method as virtual if it has no implementation?
You can make the method abstract (it will implicitly make it virtual).
Surely it can just be overwritten in the subclass without the use of virtual and override?
If you just "overwrite" it without explicitly overriding it, it won't be the same method, and calling the method on a variable of the base class won't call the derived method (it won't participate in polymorphism). You would just be "hiding" the method of the base class (the compiler actually warns you about this, if it's really what you want to do you must use the new modifier.)
An example will make it clearer:
class B
{
public virtual void M() { Console.WriteLine("B.M") };
}
class D1 : Base
{
// Hides the base method
public new void M() { Console.WriteLine("D1.M") };
}
class D2 : Base
{
// Overrides the base method
public override void M() { Console.WriteLine("D2.M") };
}
...
D1 d1 = new D1();
d1.M(); // Prints "D1.M"
B b1 = d1;
b1.M(); // Prints "B.M", because D1.M doesn't override B.M
D2 d2 = new D1();
d2.M(); // Prints "D2.M"
B b2 = d2;
b2.M(); // Also prints "D2.M", because D2.M overrides B.M
If (1) is incorrect, am I right in thinking that every virtual method must be overridden in the subclass using it....
No, only if it's abstract... a virtual method can have an implementation, and in that case derived classes are not forced to override it.
1) Is it really necessary to define a method as virtual if it has no implementation? Surely it can just be overwritten in the subclass without the use of virtual and override?
As said in other answers, virtual methods need to have implementations. You are confusing it with abstract.
If you were asking whether virtual methods which do have an implementation need to be declared virtual: In C#, yes, it is necessary. In Java, you can override any old method. It was a C# design decision to require overriding to be specifically allowed with the virtual keyword, so that methods cannot be overridden unless intended by the programmer.
If the programmer has not expressed intent by not using virtual, you can still "override" methods, with the new keyword. However, this works a bit differently. Hopefully this code will help illustrate the concept:
class Program
{
static void Main(string[] args)
{
var baseC = new BaseClass();
var extC = new ExtClass();
var lazyC = new LazyClass();
Console.WriteLine(baseC.NewMethod());
Console.WriteLine(baseC.VirtualOverrideMethod());
Console.WriteLine("---");
Console.WriteLine(extC.NewMethod());
Console.WriteLine(extC.VirtualOverrideMethod());
Console.WriteLine("---");
Console.WriteLine(((BaseClass) extC).NewMethod());
Console.WriteLine(((BaseClass) extC).VirtualOverrideMethod()); // Redundant typecast
Console.WriteLine("---");
Console.WriteLine(lazyC.VirtualOverrideMethod());
Console.ReadKey();
}
public class BaseClass
{
public BaseClass()
{
}
public string NewMethod()
{
return "NewMethod of BaseClass";
}
public virtual string VirtualOverrideMethod()
{
return "VirtualOverrideMethod of BaseClass";
}
}
class ExtClass : BaseClass
{
public new string NewMethod()
{
return "NewMethod of ExtClass";
}
public override string VirtualOverrideMethod()
{
return "VirtualOverrideMethod of ExtClass";
}
}
class LazyClass : BaseClass
{
}
}
Output:
NewMethod of BaseClass
VirtualOverrideMethod of BaseClass
---
NewMethod of ExtClass
VirtualOverrideMethod of ExtClass
---
NewMethod of BaseClass
VirtualOverrideMethod of ExtClass
---
VirtualOverrideMethod of BaseClass
2) If (1) is incorrect, am I right in thinking that every virtual method must be overridden in the subclass using it....
Not at all. virtual is a way of saying, "it's okay if you want to override this method". In fact, I included LazyClass in my code above to show this.
The above doesnt cause the compiler to complain...
I haven't used interfaces much, but that looks like one. In my code, if I change
class ExtClass : BaseClass
{
public new string NewMethod()
{
return "NewMethod of ExtClass";
}
public override string VirtualOverrideMethod()
{
return "VirtualOverrideMethod of ExtClass";
}
}
to:
class ExtClass : BaseClass
{
public new string NewMethod()
{
return "NewMethod of ExtClass";
}
public override string VirtualOverrideMethod()
{
return "VirtualOverrideMethod of ExtClass";
}
}
I get:
error CS0501: 'OverrideTest.Program.ExtClass.VirtualOverrideMethod()' must declare a body because it is not marked abstract, extern, or partial
From Visual Studio 2010. The same goes for the virtual method of my BaseClass.
The need for virtual is dictated by polymorphism. Think about what happens when you redefine a method in a subclass using new:
class Parent
{
void Foo() { Console.WriteLine("Parent"); }
virtual void Bar { Console.WriteLine("Parent"); }
}
class Child : Parent
{
new void Foo() { Console.WriteLine("Child"); } // another method Foo
override void Bar { Console.WriteLine("Child"); }
}
var child = new Child(); // a Child instance
var parent = (Parent)child; // same object, but statically typed as Parent
c.Bar(); // prints "Child"
p.Bar(); // again, prints "Child" -- expected virtual behavior
c.Foo(); // prints "Child"
p.Foo(); // but this prints "Parent"!!
For this reason, classes that are intended to be derived from (i.e. not sealed) should always mark the methods that can be overridden as virtual -- otherwise there will be confusing runtime behavior like above. There's no difference if the parent implementation actually does anything or not; the point is that it behaves differently.
ok, by declaring the method as virtual (and not wishing to override the method in the subclass), you'd be entering the world of method hiding if you were to introduce a method with the same name into the subclass. You have to define it as thus:
public abstract class A
{
public virtual string GetName()
{
return null;
}
}
public class B : A
{
//assume there are some defined properties.
public new string GetName()
{
return FirstName;
}
}
I'd recommend that you think of the abstract override approach:
public abstract class A
{
public abstract string GetName()
}
// to override
public class B : A
{
//assume there are some defined properties.
public override string GetName()
{
return FirstName;
}
}
this would be quite different. I would strongly recommend that you just override the abstract method in the subclass.
However, here's a quick ref on the subject (old but a good read):
http://www.akadia.com/services/dotnet_polymorphism.html
1) Is it really necessary to define a method as virtual if it has no
implementation? Surely it can just be overwritten in the subclass
without the use of virtual and override?
You can use an abstract methods, that have no body, but they if you derive from that class you must to override that method. All abstact methods have to be overriden in child class.
2) If (1) is incorrect, am I right in thinking that every virtual
method must be overridden in the subclass using it....
No, instead, you can use a virtual keyword to have an implementation inside that, but do not making override in a child class mandatory. Gives you more flexibility, from that point of view.
Usauly they use abstract to create rigid constrains for childs, so every child derived from it must implement specified member of base class.
That's exactly the difference between a virtual and an abstract method:
A virtual method can be overridden by derived classes if the choose to. A virtual method may or may not have a default implementation for inheritors to call into, which is done using the base keyword.
An abstract method must be overridden by derived classes. Its constraints are:
It can only be defined in an abstract class.
It cannot have an implementation, since it's up to the inheritors to define its behavior.
.Net 3.5, using C#
I have an instance of a class (A) that has been called via a virtual method from a derived class (B). Within the method (a method of class A) I have discovered the Type of class B that has made the call, and using reflection I have examined class B and discovered a property whose value I want to access.
Is there any way via reflection to get the instance reference to class B? The only object I have is my ‘this’ reference.
[ Edit ]
By way of explaining that I'm not totally nuts for needing to do this: My class is T4NmpBase (class A). I have no control over the class in which I am inheriting (TextTransformation) or the class that inherits from me (TextTemplating - class B). I would like to use the "Host" property if it exits but do not want to put any burden on the programmer who is writing the text templating code that generates the TextTransformation class.
//
// this is my class
//
public abstract partial class T4NmpBase : Microsoft.VisualStudio.TextTemplating.TextTransformation {
public override void Initialize()
{
//
// determine derived class info and get value of "Host" property if it exists
//
}
}
//
// this class is generated by T4 in a project that I have no control over
//
[System.CodeDom.Compiler.GeneratedCodeAttribute("Microsoft.VisualStudio.TextTemplating", "10.0.0.0")]
public partial class PPTest : T4_NMP_Base.T4NmpBase {
public virtual global::Microsoft.VisualStudio.TextTemplating.ITextTemplatingEngineHost Host { ... }
public override void Initialize()
{
base.Initialize();
}
}
In your case (assuming I follow correctly) your this reference is really your class (B) type, so you can use that to get the value of the property. So, just to make sure I follow correctly, you've got something that looks like:
public class ClassA
{
public virtual void VirtualMethod()
{
// Do your property investigation here
}
}
public class ClassB: ClassA
{
public override void VirtualMethod()
{
// Code for ClassB
}
}
And you are invoking the virtual method using something like:
ClassA instance = new ClassB();
instance.VirtualMethod()
So if that is the case then you should be able to get the value of the property by:
PropertyInfo proeprtyOnClassB // Assume you got this already via reflection
object propertyValue = propertyOnClassB.GetGetMethod().Invoke(this,null);
This sounds like a real problem with your design.
Is it possible to take Class B's property in question and make it a virtual property of Class A? Then you can override it in B but still access B's property from A. For example:
class A
{
public virtual string P
{
get { return "A"; }
}
public A()
{
Console.WriteLine(this.P);
}
}
class B : A
{
public override string P
{
get { return "B"; }
}
public B() : base() { }
}
When using:
B b = new B(); // prints "B"
If I understand correctly, from class A you want to access the functionality of the current instance through its concrete type B. Unless the member is not accessible to A because it's non-public, defined in another assembly, etc you don't need reflection. The following will work if the code in class A can see the members of derived class B.
B thisAsB = this as B;
if (thisAsB != null) {
// ...
}
But it does call into question the design of the class because class A should not have to know anything about its subclasses.