No, it doesn't. Expert remains Expert. A Singer remains a Singer. The fact
that a singer is a kind of expert and inherits behaviour from expert is
just the core idea of object oriented programming. Yes, it's a powerful
abstraction...

For something like skill, I would go a stage further, and use "has-some"
rather than "has-a". Many people have more than one skill. Supporting
one-to-many relationships is another advantage of composition over
inheritance.

Patricia

Thank you for your comments. Now see something new I did in the Class
MyHouse. The chair is broken. To fix it, write a class implementing
Talent interface, plug it into Expert. Now the Expert with Talent of
RepairingFurniture (a carpenter actually) is in my house now.
Expert.server() will fix the broken chair.

<code>
interface Talent
{
    void showTalent();
}

class Singing implements Talent
{
    public void showTalent()
    {
        System.out.println("do-rei-mei");
    }
}

class Painting implements Talent
{
    public void showTalent()
    {
        System.out.println("yellow, blue, red");
    }
}

class Cooking implements Talent
{
    public void showTalent()
    {
        System.out.println("gong-bao chicken");
    }
}

class Expert
{
    private Talent myTalent = null;
   
    public Expert(Talent t)
    {
        myTalent = t;
    }
   
    public void serve()
    {
        myTalent.showTalent();
    }
   
    public static void main(String[] args)
    {
        Expert anExpert = new Expert(new Singing()); //this expert is singer
        anExpert.serve();
       
        anExpert = new Expert(new Cooking()); //this expert is Chef
        anExpert.serve();
       
        anExpert = new Expert(new Painting()); //this expert is Painter
        anExpert.serve();
    }
}

public class MyHouse
{
    private boolean chairBroken = true;
   
    public boolean isChairBroken()
    {
        return this.chairBroken;
    }
   
    private class RepairingFurniture implements Talent
    {
        public void showTalent()
        {
            if (chairBroken == true)
            {
                chairBroken = false;
            }
        }
    } //end of private class
   
   
    public static void main(String[] args)
    {
        MyHouse myHouse = new MyHouse();
        if (myHouse.isChairBroken())
        {
            System.out.println("The chair needs to be fixed");
        }
        else
        {
            System.out.println("The chair has been fixed");
        }
       
        Expert anExpert = new Expert(myHouse.new RepairingFurniture());  //an
Expert with talent of RepairingFurniture (a carpenter) is in my house now.
        anExpert.serve();  //this expert will fix the chair for us!!!
       
        if (myHouse.isChairBroken())
        {
            System.out.println("The chair needs to be fixed");
        }
        else
        {
            System.out.println("The chair has been fixed");
        }
    }
}
</code>

The initialization to null is redundant.  Instance variables are initialized
to "zero-like" values (null for references) by default.

Also, stating "undecided yet" in a comment is misleading since the constructor
sets the variable in this example, so no fully-constructed instance will ever
see that "yet" moment.

In other words, all clients will see your Expert object only after it's fully
constructed, so the "yet" moment is practically non-existent.

BTW, you should probably forbid null for the constructor argument:

    public Expert(Talent t)
    {
        if ( t == null )
        {
          throw new NullPointerException( "null talent" );
        }
        myTalent = t;
    }

Otherwise serve() could throw that exception for you, but without useful
message verbiage.  That would be an example of a bug from earlier (the
constructor) showing up later (the method call), a common programming problem
that confounds analysis and repair.

- Lew