Overriding vs method hiding

Question

I am a bit confused about overriding vs. hiding a method in C#. Practical uses of each would also be appreciated, as well as an explanation for when one would use each.

I am confused about overriding - why do we override? What I have learnt so far is that by overring we can provide desired implementation to a method of a derived class, without changing the signature.

If I don't override the method of the superclass and I make changes to the method in the sub class, will that make changes to the super class method ?

I am also confused about the following - what does this demonstrate?

class A
{
    virtual m1()
    {
        console.writeline("Bye to all");
    }
}

class B : A
{
    override m1()
    {
        console.writeLine("Hi to all");
    }
}

class C
{
    A a = new A();
    B b = new B();
    a = b; (what is this)
    a.m1(); // what this will print and why?

    b = a; // what happens here?
}

Solution 1

Consider:

public class BaseClass
{
  public void WriteNum()
  {
    Console.WriteLine(12);
  }
  public virtual void WriteStr()
  {
    Console.WriteLine("abc");
  }
}

public class DerivedClass : BaseClass
{
  public new void WriteNum()
  {
    Console.WriteLine(42);
  }
  public override void WriteStr()
  {
    Console.WriteLine("xyz");
  }
}
/* ... */
BaseClass isReallyBase = new BaseClass();
BaseClass isReallyDerived = new DerivedClass();
DerivedClass isClearlyDerived = new DerivedClass();

isReallyBase.WriteNum(); // writes 12
isReallyBase.WriteStr(); // writes abc
isReallyDerived.WriteNum(); // writes 12
isReallyDerived.WriteStr(); // writes xyz
isClearlyDerived.WriteNum(); // writes 42
isClearlyDerived.writeStr(); // writes xyz

Overriding is the classic OO way in which a derived class can have more specific behaviour than a base class (in some languages you've no choice but to do so). When a virtual method is called on an object, then the most derived version of the method is called. Hence even though we are dealing with isReallyDerived as a BaseClass then functionality defined in DerivedClass is used.

Hiding means that we have a completely different method. When we call WriteNum() on isReallyDerived then there's no way of knowing that there is a different WriteNum() on DerivedClass so it isn't called. It can only be called when we are dealing with the object as a DerivedClass.

Most of the time hiding is bad. Generally, either you should have a method as virtual if its likely to be changed in a derived class, and override it in the derived class. There are however two things it is useful for:

1. Forward compatibility. If DerivedClass had a DoStuff() method, and then later on BaseClass was changed to add a DoStuff() method, (remember that they may be written by different people and exist in different assemblies) then a ban on member hiding would have suddenly made DerivedClass buggy without it changing. Also, if the new DoStuff() on BaseClass was virtual, then automatically making that on DerivedClass an override of it could lead to the pre-existing method being called when it shouldn't. Hence it's good that hiding is the default (we use new to make it clear we definitely want to hide, but leaving it out hides and emits a warning on compilation).

2. Poor-man's covariance. Consider a Clone() method on BaseClass that returns a new BaseClass that's a copy of that created. In the override on DerivedClass this will create a DerivedClass but return it as a BaseClass, which isn't as useful. What we could do is to have a virtual protected CreateClone() that is overridden. In BaseClass we have a Clone() that returns the result of this - and all is well - in DerivedClass we hide this with a new Clone() that returns a DerivedClass. Calling Clone() on BaseClass will always return a BaseClass reference, which will be a BaseClass value or a DerivedClass value as appropriate. Calling Clone() on DerivedClass will return a DerivedClass value, which is what we'd want in that context. There are other variants of this principle, however it should be noted that they are all pretty rare.

An important thing to note with the second case, is that we've used hiding precisely to remove surprises to the calling code, as the person using DerivedClass might reasonably expect its Clone() to return a DerivedClass. The results of any of the ways it could be called are kept consistent with each other. Most cases of hiding risk introducing surprises, which is why they are generally frowned upon. This one is justified precisely because it solves the very problem that hiding often introduces.

In all, hiding is sometimes necessary, infrequently useful, but generally bad, so be very wary of it.

Solution 2

Overriding is when you provide a new override implementation of a method in a descendant class when that method is defined in the base class as virtual.

Hiding is when you provide a new implementation of a method in a descendant class when that method is not defined in the base class as virtual, or when your new implementation does not specify override.

Hiding is very often bad; you should generally try not to do it if you can avoid it at all. Hiding can cause unexpected things to happen, because Hidden methods are only used when called on a variable of the actual type you defined, not if using a base class reference... on the other hand, Virtual methods which are overridden will end up with the proper method version being called, even when called using the base class reference on a child class.

For instance, consider these classes:

public class BaseClass
{
  public virtual void Method1()  //Virtual method
  {
    Console.WriteLine("Running BaseClass Method1");
  }
  public void Method2()  //Not a virtual method
  {
    Console.WriteLine("Running BaseClass Method2");
  }
}
public class InheritedClass : BaseClass
{
  public override void Method1()  //Overriding the base virtual method.
  {
    Console.WriteLine("Running InheritedClass Method1");
  }
  public new void Method2()  //Can't override the base method; must 'new' it.
  {
    Console.WriteLine("Running InheritedClass Method2");
  }
}

Let's call it like this, with an instance of InheritedClass, in a matching reference:

InheritedClass inherited = new InheritedClass();
inherited.Method1();
inherited.Method2();

This returns what you should expect; both methods say they are running the InheritedClass versions.

Running InheritedClass Method1
Running InheritedClass Method2

This code creates an instance of the same, InheritedClass, but stores it in a BaseClass reference:

BaseClass baseRef = new InheritedClass();
baseRef.Method1();
baseRef.Method2();

Normally, under OOP principles, you should expect the same output as the above example. But you don't get the same output:

Running InheritedClass Method1
Running BaseClass Method2

When you wrote the InheritedClass code, you may have wanted all calls to Method2() to run the code you wrote in it. Normally, this would be how it works - assuming you are working with a virtual method that you have overridden. But because you are using a new/hidden method, it calls the version on the reference you are using, instead.

---

If that's the behavior you truly want, then; there you go. But I would strongly suggest that if that's what you want, there may be a larger architectural issue with the code.

Solution 3

Method Overriding is simpley override a default implementation of a base class method in the derived class.

Method Hiding : You can make use of 'new' keyword before a virtual method in a derived class

as

class Foo  
{  
  public virtual void foo1()  
  {  

  }  
}  

class Bar:Foo  
{  
  public new virtual void foo1()  
  {   

  }  
}  

now if you make another class Bar1 which is derived from Bar , you can override foo1 which is defind in Bar.

Comments

[thecoop]

I wouldn't say you should never hide a method. Sometimes, I find hiding very useful (for, say, changing the return value to a subclass)

[Andrew Barber]

That's why I said you should -try- to never do it :)

[NoviceToDotNet]

y can ti use virtual with override key word if in your example i do....class myclass:bar{ then it will get the Foo class foo1() or bar class foo1() to override it} also if in bar class insted of hiding the foo1() i override it and i put virtual before it then will it be inherited to myClass and again by puting override can i override the method of Bar class foo1() to myClass

[Jon Hanna]

Yes, but in case @thecoop mentions you want to very deliberately try to hide. The main thing I think is that normally hiding can introduce nasty surprises, but in using it for covariance you actually remove surprises.

[Jon Hanna]

@NoviceToDotNet No, virtual can be used in a class derived from Bar, but it will override Bar.foo1 and not Foo.foo1. The above mixture of hiding and virtual is valid, though in combining the two together perhaps not the best explanation of the difference between the two.

[NoviceToDotNet]

sir what if i use public virtual void WriteNum() and in sub claass .....i use public new virual void WriteNum() what method will be called on isReallyBase.WriteNum(); and y

[Jon Hanna]

@NoviceToDotNet using new virtual means it hides the more derived version, but can itself be virtual. If you call WriteNum() on either isReallyBase or isReallyDerived then the version defined in BaseClass would be called, as it isn't overriden, but if you called it on isClearlyDerived then the hiding version will be called. Further, you could have an override in a further subclass (say "DerivedFromDerivedClass") and this override would be called when DerivedFromDerivedClass is manipulated through a DerivedFromDerivedClass variable or a DerivedClass variable...

[NoviceToDotNet]

and also in case if we dot't override the method of super class bcas it's not compulsory then what it will do isReallyDerived.WriteStr();

[Jon Hanna]

... but if the DerivedFromDerivedClass had it invoked through a BaseClass variable, then only that defined in BaseClass would be called. One way to think about it is that base classes "know" that virtual members can be overridden (and override members can be overridden again), and will "look" for those overrides, but they can't "see past" any hiding members.

[NoviceToDotNet]

sir 1 confusion u told "When a virtual method is called on an object, then the most derived version of the method is called. "...............then y isReallyBase.WriteStr(); // writes abc .. ......not prinithing writes xyz

[Jon Hanna]

isReallyBase is a BaseClass (BaseClass isReallyBase = new BaseClass();) so what happens in DerivedClass has nothing to do with it.

[NoviceToDotNet]

and also u told it look 4 most derived class it means if have a class..myclass:derived class and it has mehod overriding public override void WriteStr(){some code} then isReallyDerived.WriteStr(); will call code written in myclass method?

[Jon Hanna]

isReallyDerived will call the version defined in DerivedClass because that's the most derived version applicable to something created with new DerivedClass() but if we did isReallyDerived = new MyClass() then the version defined in MyClass would be called.

[brighty]

Does the "feature" of hiding a method violate the LSP?

[Andrew Barber]

@brighty Apologies for a very late response, and you've probably already found the info, but yes, it does violate LSP. In fact, that's basically the core of LSP that "hiding" violates.

[Douglas Gaskell]

@JonHanna Another use-case for hiding you may want to consider is poor-mans aspect-orientated (AO for brevity) programming. C# doesn't support AO, and in some cases the same chunks of logic are needed in multiple entities (ie. in DDD), but can't be abstracted out (ie. private fields). This can be hacked around with a base "god class" that contains this shared logic. Props & Methods are protected, derived classes hide them and change the access to public, and call the base class method. It's a hack, goes against all the rules, but it's saved me ~25k of repetitive LOC and kept things DRY.