Confused about quote fom Microsoft about abstract classes?

Microsoft states in regards to abstract classes "They also version well, because if additional functionality is needed in derived classes, it can be added to the base class without bre开发者_StackOverflowaking code."

If I add additional functionality to a base class, wouldn't this break the derived class, for example, if I added another abstract method, all the derived classes would now have to implement this method, or am I misreading the quote.

Here is a link to original article.

In 2010 your code

public abstract class Animal{
    public abstract void eat();
}

public abstract class Human extends Animal{
    public  void eat(){
               //eat rice
    }
}

and your method

feedAnimal(Animal a){
  a.eat();//it will eat rice for code in 2010
}

Now in 2015, you have got new version

public abstract class Human extends Animal{
    public  void eat(){
        //eat rice + milk
    }
}

Now if you invoke feedAnimal(); it will eat rice + milk

I hope it clears up the things well ;)

I'd argue that adding an abstract method to a superclass does not constitute adding "additional functionality" and that they were simply referring to being able to access new methods added to the superclass in new subclasses at a later date.

I agree though. It's pretty misleading.

There is an idea in OOP that you should only inherit from abstract classes and interfaces. The article seems to tacitly assume this. Thus, the comment about versioning relates to the relative advantages of using an abstract class vs. an interface.

C# and VB encourage excessive use of inheritance since classes are not sealed by default.

See:

Why aren't classes sealed by default?
Why aren't classes sealed by default?
Why does the 'sealed' keyword exist in .Net?
http://oredev.org/2010/sessions/c-s-greatest-mistakes

I guess, it means the following

public abstract class myBase
{
    public abstract void sayHello();
}

public class child : myBase
{
    public override void sayHello()
    {
        Console.WriteLine("hello");
    }
}

Let's say, you want to add a new method in derived class(es) that should also be in base class, you could do

public abstract class myBase
{
    public abstract void sayHello();
    public virtual void saySomething()
    {
        Console.WriteLine("default something");
    }
}

public class child : myBase
{
    public override void sayHello()
    {
        Console.WriteLine("hello");
    }
}

Here, the code adds the default implementation in the base class & it won't break any other code. Also, derived classes can provide for overrideen behavior, if it differs from base's saySomething.

With this in mind, inherting class(es) can provide for its own implementation.

public abstract class myBase
{
    public abstract void sayHello();

    // here, if one can throw `NotImplementedException` 
    public virtual void saySomething()
    {
        Console.WriteLine("default something");
    }
}

public class child : myBase
{
    public override void sayHello()
    {
        Console.WriteLine("hello");
    }

    public override void saySomething()
    {
        Console.WriteLine("child said something");
    }
}