Composition over Inheritance

We had often heard that composition is better than inheritance. Why is it so? First of all how is one different from the other and what are the similarities in them?

Lets say we are writing simulation software for Rocket Launching systems which are to be supplied to different countries. Now these different countries can use them as they want it.
The code for our launching system is below:
public class Launcher{
    public bool LaunchMissile()
    {
        Console.WriteLine("Missile launched");
        return true;
    }
}public class SufraceToAirMissileLauncher:Launcher{

 }
Now, country A uses this code to launch missile as follows:
static void Main(string[] args)
    {
        SufraceToAirMissileLauncher staLauncher = new SufraceToAirMissileLauncher();
        bool isLaunched =   staLauncher.LaunchMissile();    }

This is how Inheritance is used. The various launchers can reuse the base Launcher class code to launch missile.

The same thing can be achieved by using Composition where base class functionality is encapsulated inside the main concrete class. The code for that is below:
public class SufraceToAirMissileLauncher{
    private Launcher launcher = new Launcher();
    public bool LaunchMissile()
    {
        return launcher.LaunchMissile();
    }}
The client UI code remains the same.

Now due to our superb code, our patented launching software had become famous and another country B wants to use it. But they had a condition that instead of launching the missile through base class they would want to get an instance of a missile. Now it's up to them what they want to do with it. They might add some nuclear material on it or modify it to increase its range or do whatever they might like. So another Missile object comes into the picture.
public class Missile{
    private bool isLaunched;
    public bool IsLaunched
    {
        get { return isLaunched; }
        set { isLaunched = value; }
    }
    public Missile(bool isLaunched)
    {
        IsLaunched = IsLaunched;
    }}

And the base class function has changed to:

public class Launcher{
    public Missile LaunchMissile()
    {
        Console.WriteLine("Missile returned");
        return new Missile(true);
    }}

Now it returns a missile instead of launching it. So now if we rely on inheritance, the client code of country A would break since the method signature has changed from what is being used in its UI.

However, if the country A had used composition instead, the code will not break. Only the derived class function would need to accommodate the new changed behavior of the base class. To accommodate this, we need to change our derived class code function "LaunchMissile" as:
public class SufraceToAirMissileLauncher{
    private Launcher launcher = new Launcher();
    public bool LaunchMissile()
    {
        Missile missile = launcher.LaunchMissile();
        return missile.IsLaunched;
    }}

Hence, the client code of country A would still work:

static void Main(string[] args)
    {
        SufraceToAirMissileLauncher staLauncher = new SufraceToAirMissileLauncher();
        bool isLaunched =   staLauncher.LaunchMissile();    }
On the other hand country B which was insisting on getting a missile would still get missile from the base class.

So through this simple example we see how the composition is favored over inheritance to maintain compatibility and where there is a possibility that the functionality might change in future.