[KnowThySelf]

Whats the point in making abstract methods if you have to override them anyway in a derived class and you don't even define the body?
it seems like its just a waste of time. I understand what inheretance is and I see why polymorphism is useful. Not all animals are frogs, but all animals eat. I get it. But whats the point of the abstract method if there is no body to it anyway and I have to rewrite everything with override in my new class inheriting the abstract class.

[macosxnerd101]

The point is that it guarantees the method is in the subclass. If you know all Animals eat(), then you can have a List<Animal> and safely call eat() on all the elements without having to do instanceof checking with the is keyword.

[KnowThySelf]

So I have to re-implement the methods in each morph of the class like the cat and the dog. Why? because not all animals eat() the same way?

[macosxnerd101]

That is correct. Look at it this way- if you don't place eat() as an abstract method, then you cannot guarantee that it can be called on all Animals. So if you have a List<Animal>, you will have to test if the element in question is a Dog or Cat before invoking eat().

[Curtis Rutland]

To understand abstract methods, you have to understand abstract classes, since in C#, you cannot use abstract methods anywhere else (except for interfaces; interface methods are implicitly abstract). Abstract classes are similar to interfaces, but they allow you to implement some, all, or no methods, where as interfaces do not allow you to implement any. What that means is that in an abstract class, I can have both abstract and non-abstract methods. That's a very nice feature when I know some functionality must be consistent across all derived classes, and some must be implemented at the derived level.

That brings us to abstract methods. That's what allows us to leave implementation to the base classes. But by virtue of declaring it on the base class, we can call the method on any derived class. Here's a contrived example:

abstract class Animal
{
    public void Die()
    {
        Console.WriteLine("I'm Dead.");
    }

    public abstract void Speak();
}

class Dog : Animal
{
    public override void Speak()
    {
        Console.WriteLine("Bark");
    }
}

class Cat : Animal
{
    public override void Speak()
    {
        Console.WriteLine("Meow");
    }
}

public static void Main()
{
    var animals = new List<Animal>();
    animals.Add(new Cat());
    animals.Add(new Dog());
    animals.Add(new Cat());
    foreach (var a in animals)
    {
        a.Speak();
        a.Die();
    }
    Console.ReadKey();
}

As you can see, we can call Speak on Animals without casting to a Cat or Dog. That's the real power of abstract methods. It allows us to defer implementation to the derived class, but guarantees that the method will be available from all derived classes.

A less contrived example involves the WebRequest and WebResponse classes, which are abstract. But there are multiple derived classes, including Http, Ftp, and File. But all of them have a GetResponseStream method, because it's abstract. So we could take a list of all kinds of WebRequests, without knowing if they're Http, Ftp, or File, and still process them all the same.