有一天，FHAM(FamilyHuAIMu)游戏团队队员小言说：接到一个活，需要咱们设计一款“鸭子群”游戏，大家开始讨论......

小胡：最简单的思路就是设计一个鸭子父类（鸭子祖类，父类中有红色，绿色，蓝色，铁鸭子，泥巴等属性，然后有游泳，吃喝拉撒睡等方法），然后然接下来的一群不同的鸭子分别继承这个父类，从而构造出我们自己的鸭子群（会飞的蓝鸭子，只会游泳不会飞的红鸭子等等）。大家便开始干并交付给用户。

（旁白）大家想一想这样一来会不会出现什么问题呢
过了一周......

小言:用户嫌弃咱们鸭子群的，反馈回来说：我想让我的鸭子飞上天，与太阳肩并肩......，要不直接给父类鸭子加上飞翔方法吧。行呀，交给你了，干掉他。

小胡：因为用的继承嘛，给那个鸭子父类加上飞方法后，鸭子们不久全都会飞了。不过，后来发现铁鸭子，泥巴鸭子也会飞了......由于违反常识，可能会带坏小朋友，咱们的鸭子群游戏被封杀了。

（旁白）所以得出一个结论，不能滥用继承

又过了一周，游戏团队队员小言觉得不甘心，说：“那不用继承了，咱们可以把鸭子父类中的飞翔呀，吃饭呀，睡觉呀，学习呀等等方法分别都封装为独立的接口，然后让之前的鸭子子类们谁需要什么方法，直接去父类中实现重写就行了呗，这总不会出错吧。”

（旁白）分开代码中常变化和不经常变化的部分---鸭子游戏，那就先分为两组呗

小胡：你意思是不是这样，把飞方法单独拿出来，放在一个飞家口中，然后算上鸭子父类就有一个飞接口，一个鸭子父类。让鸭子群中谁想飞谁就来实现这个飞接口，并且重写接口中的飞方法。然后后期鸭子群中哪个子鸭子还想有父类鸭子中的哪个行为，咱就把父类鸭子中的那个方法继续拿出来放到一个接口中，让那个想要这个行为的子鸭子来实现这个接口并重写接口中的方法就行了。

小言：可以倒可以，不过要是这样干，那代码会不会有点浪费呢，一个类中只有一个方法

小胡：是可以有属性的，你想呀，最起码不谈另外的属性，就飞翔这个方法本身。你看飞翔的频率呀，翅膀的大小呀，飞翔的距离呀等等，都可以算作属性，用在类中呀，这不是目前用不到嘛。

小胡：对了，你看看我前几天看到的一个东西

public abstract class Duck{//这是鸭子父类
Fly f1;

public Duck(){}//鸭子父类的构造器

public