Can someone explain the difference between an override and just a normal method, and when an override should be used over the latter?
Every tutorial I have found uses words like "Polymorphism" and "Derived Classes" rather than just explain their application and when they should be used.
I am using C# in particular but an understanding of overrides as a concept would be very helpful.
Thanks for any input on the subject.
Simply put, overrides are for when you want to change the behavior of a method in a derived class. For example, say you had an Animal.Speak() method:
class Animal
{
public virtual void Speak()
{
Console.WriteLine("The animal makes random animal noises.");
}
}
Now, if you had a specific type of animal, you'd want to override that Speak() method to make noises that that type of animal would make:
class Dog : Animal
{
public override void Speak()
{
Console.WriteLine("The dog barks.");
}
}
Now if you make a Dog object and tell it to speak, it will bark. Now let's consider if you had a Cat class but didn't override the Speak() method:
class Cat : Animal
{
}
If you had this code:
Animal dog = new Dog();
Animal cat = new Cat();
dog.Speak();
cat.Speak();
You'd see this:
The dog barks.
The animal makes random animal noises.
For example, if there is an predefined class which has a method "ABC" and you want to change its behavior. In that case you have to write the keyword override before the method ABC that you want to change from its default to what you really want to have. Simple words use override when you have to change already existing method. Do not use override when you are creating a new method of any object which already does not exists.
Overriding occurs when you make a method/function/subroutine that has the same name as another function, but has different functionality. One prominent example is the Equals method. This method can be overridden for a custom object to return your concept of equality. For example, if you have a Person object and decide that 2 Persons are equal when they have the same name, you could override the existing Equals method to return whether or not 2 Persons have the same name. Good luck!
What do you mean by "overriden" method?
There are two options:
Override virtual methods in subclasses. Here "method overriding" is a part of polymorphism - one of the concept of object-oriented programming.
For instance, here you have a base class A with some virtual methods:
public class A
{
public void Method1() {}
public virtual void Method2() {}
public virtual void Method3() {}
}
If you create class B, which is derived from A you will have an opportunity to override virtual methods in such case:
public class B : A
{
public override void Method2() {}
public override void Method3() {}
}
In such way you change your base functionality from class A by your new functionality from class B.
So, when you call method from instance of class B , you will get functionality from overriden method in class B:
B instanceB = new B();
instanceB.Method2();
Override method signature. Here you are able to have multiple methods with same name, but with different signatures.
For example, you have such class with 3 methods, which have one name TestMethod, but there are different signatures (different input and output parameter types):
public class TestClass
{
public void TestMethod() {}
public int TestMethod(int value) {}
public string TestMethod(int value) {}
}
Related
abstract class A<T> where T:A<T>
{
public event Action<T> Event1;
}
class B : A<B>
{
//has a field called Action<B> Event1;
}
Is there a more elegant way to do this? I want stuff (events, etc) in the base class to be able to use the subclass' type.
The pattern you are using does not actually implement the constraint you want. Suppose you want to model "an animal can only be friendly with something of its own kind":
abstract class Animal<T> where T : Animal<T>
{
public abstract void GetFriendly(T t);
}
class Cat : Animal<Cat>
{
public override void GetFriendly(Cat cat) {}
}
Have we succeeded in implementing the desired constraint? No.
class EvilDog : Animal<Cat>
{
public override void GetFriendly(Cat cat) {}
}
Now an evil dog can be friendly with any Cat, and not friendly with other evil dogs.
The type constraint you want is not possible in the C# type system. Try Haskell if you need this sort of constraint enforced by the type system.
See my article on this subject for more details:
http://blogs.msdn.com/b/ericlippert/archive/2011/02/03/curiouser-and-curiouser.aspx
What you have works very well. In fact it's very similar to other .NET interfaces and types where you want the interface implementer to use your type, like:
public class MyClass : IEqualityComparer<MyClass>
{
// From the interface IEqualityComparer
public bool Equals(MyClass other) { ... }
...
}
I don't think you need to specify where T:A.
T will be B when you use class B:A
This is also known as CRTP or Curiously recurring template pattern and is a known idiom.
Since A is abstract, you can add abstract methods to A and invoke them from A and B, which will be forced to implement the method, will be the invoker:
abstract class A<T> where T:A
{
public event Action<T> Event1;
public abstract void Method();
public A(){Method();}
}
class B : A<B>
{
//has a field called Action<B> Event1;
public void Method(){ //stuff }
}
On instantiation of B, the base class constructor will call Method() which is only implemented in B, forcing B's instance to be called.
This allows A to invoke subclass specific methods without requiring A to have specific knowledge of Children. The downside is that ALL children must implement Method or re-abstract it to their own children.
My most recent question was marked as a duplicate of this one. I totally agree on that matter. So I came here to take a look at the answers and to read Eric's post on that (very interesting indeed). You can not enforce this at compile time with the type system but you can do this at runtime. The way I implemented this is:
abstract class FooBase<T>
{
protected FooBase()
{
if (typeof(T) != GetType())
{
throw new InvalidOperationException();
}
}
}
By doing this we can plant the seed of an evil dog, but that dog will be aborted at runtime.
A coworker introduced me to the concept of hiding implementation details through allowing the derived class to override the private field initializations.
For example I have a base class:
public class Animal
{
private Dog dog;
private Cat cat;
private Mouse mouse;
protected virtual void Init()
{
dog = new Dog();
cat = new Cat();
mouse = new Mouse();
}
public void DoStuff() {}
}
This allows me to override the initialization within a derived class of the base class privates:
public class Cookie : Animal
{
protected override void init()
{
//do whatever i want here
}
}
Does this type of implementation-detail-hiding have a name?
Would I ever call Init() from Animal or does this pattern insist on Init() because called from a derived class?
What am I trying to achieve?
I have a class (animal in the example above) that has about 20 private objects that need to be initialized, and I want to be able to define my own way of initializing them specifically when doing unit testing.
1) This is simply overriding, i am not aware that it is more than that. But you cannot access private fields in a subclass, they have to be protected as well so you can access them in your subclass.
2) Your question is not clear, but i am guessing you are asking how you can call the method of the base class from within the override. all you need to do is
public class Cookie : Animal
{
protected override void init()
{
//do whatever you want here
base.init(); //This line will call the init() function in Animal.
//do whatever you want here
}
}
That is simply called override.
An override method provides a new implementation of a member that is
inherited from a base class.
You can invoke the base class' overriden method Init() from the derived class by using base.Init();.
I am implementing a collection of classes that exhibit the following pattern:
public class Animal {}
public abstract class AnimalToy
{
public AnimalToy(Animal owner)
{
Owner = owner;
}
public Animal Owner { get; private set; }
/* Various methods related to all toys that use the Owner property */
}
public class Dog: Animal
{
public void Bark() {}
}
public class PlasticBone: AnimalToy
{
public PlasticBone(Dog owner) : base(owner) {}
public void Throw()
{
((Dog)Owner).Bark();
}
}
I have a base class AnimalToy with a property that is a reference to another base class Animal.
I now want to implement a Dog and a PlasticBone toy for that Dog class. PlasticBone is a toy that's only valid for dogs, and in fact the constructor restricts the owner of PlasticBone to be of type Dog.
PlasticBone has a method Throw() that is unique to that class, that uses a method on Dog (Bark()) that is unique to the Dog class. Therefore I need to cast the generic property Owner to Dog before I can access it.
This works just fine, but in the project I am working on this situation comes up again and again and leads to quite ugly code where the methods of derived classes are full of downcasts of base class references. Is this normal? Or is there a better overall design that would be cleaner?
Here's one way to fix it:
public abstract class Animal
{
public abstract void MakeNoise();
}
Let dog implement the MakeNoise and you can just call that in your Toy class:
public void Throw()
{
Owner.MakeNoise();
}
You can make AnimalToy class generic, by this you can avoid casting.
public abstract class AnimalToy<TAnimal> where TAnimal : Animal
{
public AnimalToy(TAnimal owner)
{
Owner = owner;
}
public TAnimal Owner { get; private set; }
}
public class PlasticBone: AnimalToy<Dog>
{
public PlasticBone(Dog owner) : base(owner) {}
public void Throw()
{
Owner.Bark();
}
}
Worth noting that ((Dog)Owner) is not upcast, it is called downcast. upcast is over way around.
I'm going to try to elaborate a little on the discussion in the comments and hopefully provide you with a generalised, polymorphic solution. The general idea is functionally equivalent to what Carra was suggesting but, hopefully, this will help you to apply those concepts to the domain of your actual problem.
To work with your abstraction of your problem; suppose you have your abstract base class defined like so:
public abstract class Animal
{
public abstract void Catch();
}
This is a shift in the semantics of the abstract method; you no longer have an abstract Bark method, you simply have a Catch method, the semantics of which define it as, essentially "react to something being thrown." How the Animal reacts is entirely up to the animal.
So, you'd then define Dog like so:
public class Dog : Animal
{
public override void Catch()
{
Bark();
}
public void Bark()
{
// Bark!
}
}
And change your Throw method to:
public void Throw()
{
Owner.Catch();
}
Now, Bark is specific to Dog, while the generic Catch method is universal to all Animals. The Animal class now specifies that its subclasses must implement a method that reacts to items being thrown to it. The fact that the Dog barks is entirely up to the Dog.
This is the essence of polymorphism - it's not up to the toy to determine what the dog does; it's up to the dog. All the toy needs to know is that the dog can catch it.
More generally, though, I don't like to have two classes that extend independent base classes be logically coupled (parallel hierarchies, as Eric points out) unless one of them explicitly instantiates the other, though it's impossible to offer any real advice on that without seeing your actual solution architecture.
Given
public class Animal
{
public Animal()
{
Console.WriteLine("Animal constructor called");
}
public virtual void Speak()
{
Console.WriteLine("animal speaks");
}
}
public class Dog: Animal
{
public Dog()
{
Console.WriteLine("Dog constructor called");
this.Speak();
}
public override void Speak()
{
Console.WriteLine("dog speaks");
base.Speak();
}
}
this.Speak() calls Dog.Speak(). Remove Speak() from dog and suddenly this.Speak() calls Animal.Speak(). Why does this behave this way? In other words, why does this mean base or this?
To me, an explicit call to base.Speak() makes more sense. Especially when speak is not virtual, surprisingly Speak() is still called when virtual is removed. I understand IS-A relationships from an OO sense, but I can't wrap my head around this specific problem in C#. This gets especially annoying when people write God class UI's (practically every business does). I'm looking for "Speak()" inside "this" when I should be looking at "base".
Subclases automatically inherit behavior from their base classes. If you don't do anything other than inherit Dog from Animal then this.Speak() and base.Speak() both reference the version of Speak() that was implemented in Animal.
Where special things start happening is if Dog overrides Speak(). This is not possible unless Speak() is virtual. (The virtual keyword doesn't control inheritance, it controlls overriding.)
Only when Dog overrides Speak() does base.Speak() do something special: In that case, calling Speak() (or this.Speak()) will execute Dog's implementation, because it overrides Animal's implementation. This is where base becomes useful: it allows you to get around this behavior by specifying that you want to execute the base class's implementation rather than the override.
A common use of this style is in constructors. For example:
public class Animal
{
private readonly string _name;
public Animal() : this("Animal") { }
protected Animal(string name) { _name = name; }
public void Speak() { Console.WriteLine(_name + " speaks"); }
}
public class NamedAnimal : Animal
{
public NamedAnimal(name) : base(name) { }
}
// usage:
(new Animal()).Speak(); // prints "Animal speaks"
(new NamedAnimal("Dog")).Speak(); // prints "Dog speaks"
In this example, NamedAnimal doesn't have access to the _name field, but it is still able to set it indirectly by calling the base class's constructor. But the base class's signature is the same as one in the base class, so it has to be specified using base.
With non-constructors it's also useful to get at behavior that's not otherwise accessible. For example, if Animal.Speak were virtual then we could use an override to tack behavior onto it rather than simply replacing it:
public class NamedAnimal : Animal
{
public NamedAnimal(name) : base(name) { }
public override Speak()
{
Console.Write("The animal named ");
base.Speak();
}
}
// usage:
(new NamedAnimal("Dog")).Speak(); // Writes "The animal named Dog speaks"
Its not that. Its that if there is a speak method within dog, then it is an override of the base method. If it isn't there, then calling dogInstance.Speak will look for the Speak() method in any of Dog's base classes.
This is one of the very fundamental points of OO. If you don't provide an override, then the parent method is used.
Also, even if you remove virtual, Dog.Speak is called because you're not accessing this polymorphically.
this means this and nothing else.
Just in your first example you have an override for Speak(..) function, so this call that one.
In second case, istead, there is no any override, so it "climbs" on derivation tree and pick the first suitable function. In your case that one is Speak(..) of the Animal.
VB.Net has the MyClass keyword to do just that (as opposed to the My keyword, which is the equivalent of this in C#). Unfortunately, there is no MyClass equivalent keyword in C#.
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.