Determining what child class is inheriting a base class?

Is there a built-in way in C# for a base class to determine what type of child class is inheriting it?
For example, there are child classes B and C which derive from A. In class A, can I determine who is calling the Bar() function? Or is it required for class B or C to pass in a reference to itself, or its type into the Bar function?
Since class A is abstract, an instance of it must correlate to either B or C, right?
It seems like it would be possible for the C# runtime to know this information somewhere, and to have some type of keyword similar to “base”.

public abstract class A
{
  protected void Bar()
  {
      //Who is inheriting me? B or C?
   }
}
public class B : A
{
  void Foo()
  {
    base.Bar();
  }
}
public class C : A
{
  void Foo()
  {
    base.Bar();
  }
}

why would it have to pass a reference to itself? It is itself.

‘this’ in method ‘Bar’ would be a reference to itself.

What I’m wondering is WHY you need to know if you’re a B or a C in A… if this is a requirement, there is probably something fundamentally wrong with your code. A base class should not be concerned with what types inherited from it.

Any code specific to how B or C acts should be in B or C.

This is why ‘override’ exists, so B can ‘override’ the way ‘Bar’ acts.

(note - you also don’t have to say ‘base.Bar’, you could just say ‘this.Bar’… inheritance means you are an A, so you have a method called Bar)

anyways, to answer you’re question. You can test if an object (including ‘this’) is a type.

if(this is B) //do stuff

But I repeat… if you’re doing this, there is probably something terribly wrong with your code.

2 Likes

I concur. Often, when writing especially large methods, a programmer finds that he needs to diverge the execution path of that method based on the derived type of the class. When this happens, the programmer should instead split up the method into constituent parts, and call them sequentially, using overrides to alter the logic. When methods are large, with lots of nested statements and large blocks of code, they are hard to change. This is why we say that some code is brittle, and resistant to change. Splitting the large methods into several chained method calls allows subclasses to more easily alter the part that they need to, without violating open-closed.

Athough you may want to avoid calling the Bar() method of your derived type, and jump right to the base implementation in some circumstances. So it is valid to call base.Bar() when you know that is what you want.

1 Like

Like others said, your base class should be unaware of the types inheriting from it. That said, sometimes class comparisons from the base class are needed, and can be done without being type specific. Maybe you have one of these situations.

if (this.GetType() == target.GetType()

Thanks lord. The keyword “is” is what I was hoping for.
Thanks all for the info here.
Note: In reality I have no need to do this. I just wondering how it could be done just out of my own curiosity. I’ve scowered through the internet and cannot find any examples of anyone needing to do this, so like everyone has said here, it must be very bad OO practice to need to do this,