Can anyone explain me what's the point of overriding base class implementations (if its not abstract), because it's not ethical move to modify features of the parent class according to the wishes of derived classes. The best way is to make the base classes abstract and carry on the inheritance chain. Whereas when designing a class hierarchy initially we gather or elicit all the essential requirements/features that should be belonged to a base class. Therefore, in a middle of a project we do not need to change base class implementations. According to my knowledge, base class implementation should be a constant. Thus, under this aspect, there's no real use of "override" keyword in c#. If it's not so please explain me with an example.

  • 7
    If the base class wants derived classes to be able to modify that particular behavior they make the method virtual. If they don't, they leave it sealed. It is up to them whether they want to allow it or not. As to why the feature exists, it's to support polymorphism.
    – Servy
    Sep 17, 2013 at 19:41
  • Saying it's polymorphism,why we need to override base class implementation.Base class is like a prototype or semantic for derived classes.Most Ethical way is overriding methods of derived classes,isn't it?
    – Wageesha
    Sep 17, 2013 at 19:51
  • @Wageesha - Does my example help explain it?
    – Bobson
    Sep 17, 2013 at 20:18
  • @servy: No, the base class does not want its behaviour modified as per the Liskov Substitution Principle, but may want to enable derived classes to add to it. Sep 18, 2013 at 10:05

5 Answers 5


Many times you will have dependencies in sub-classes, or may have to implement things differently.

class BasicCarModel
    public virtual void Accelerate(double speed)

class LuxuryCarModel : BasicCarModel
    public override void Accelerate(double speed)

There is nothing at all wrong with creating virtual methods in concrete classes and in some cases they are very useful. The difficulty is that many novice programmers violate the Liskov Substitution Principle when doing so. Remember that an overridden method should appear to do the same thing if used as a base method. It should not strengthen or weaken the preconditions of the base method.

In the example I gave, the difference between the base class and the derived class was in the mechanics of how the car accelerated, not in the values allowed for speed. It did not throw any exceptions that were not expected by a calling class.

This is a contrived example, but the principle is the same. Do use virtual and override when needed. Don't violate the LSP.


Here's a non-abstract class which does some processing, and a sub class which only does processing at certain times of day.

class Foo
    public virtual bool IsReadyToProcess()
        return true;
    public void Process()
        if (!IsReadyToProcess()) throw new Exception("Not ready");
          // Process

class TimeboundFoo : Foo
    public TimeboundFoo(int hour) { Hour = hour; }

    public int Hour { get; private set; }

    public override bool IsReadyToProcess()
       return DateTime.Now.Hour == Hour;


List<Foo> foos = new List<Foo>();
foos.Add(new Foo());
foos.Add(new TimeboundFoo(12));

foreach (var foo in foos)
   if (foo.IsReadyToProcess()) foo.Process();

At noon, it'll process both Foo objects, but at any other hour it'll only process the one. It's a very contrived example, but you can generalize from here.


Virtual/abstract methods and overriding are commonly used in. Template pattern.

The template pattern provides a way to define what you think would be a good general guideline for a class to follow, but you allow future implementers to be more specific, or even unique in their way of doing something.

  • Note that Template pattern provides a guideline for adhering to the LSP. Future implementers should refer to the Template. If you find your overrides does not fit the template, you are probably violating LSP Sep 19, 2013 at 1:40

How about a simple case where you MUST use override:

Any class that implements the IDisposable interface. (And any class that owns a resource that must be cleaned up should implement it.)

  • Yeah well he does understand that point in his discussion of the abstract classes which are "similar" from this point of view. He's discussing the ability of being able to override any method that has been previously implemented.
    – SRKX
    Sep 20, 2013 at 6:59
  • @SRKX He understands it can happen but I don't think he understands why it's often a good thing. Sep 20, 2013 at 15:07

Note: The OP mention that it seems OK to you to override base implementations of abstract classes, so this answer is tailored around that assumption.

It's probably a bad idea to inherit from classes which were not designed for inheritance (see why are concrete types rarely useful as bases for further derivation). Many of the C# experts believe that C# classes should be sealed by default.

See also Why Are So Many Of The Framework Classes Sealed?.

All that being said, the only difference between an abstract class and a concrete class that was designed for inheritance is that the latter can be instantiated. Alternatively, a concrete class is like an abstract class that has no methods lacking some form of default implementation. All of the design considerations that make it OK to inherit from an abstract class also make it OK to inherit from a concrete class that was designed for inheritance.

An interesting example is UserControl. Being able to derive from UserControl is of high value, since there is a lot of asp.net functionality which leverages polymorphism.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.