为什么要多态？
一般来说，伴随着接口和类的继承，多态就会产生。在多态的过程中，我们需要关注其中的一些要点。
首先我们来演示一下类的继承。
父类和子类：
public class Zi extends Fu{
public void play(){
System.out.println("钓鱼");
}
}
public class Zi extends Fu{
public void play(){
System.out.println("LOL");
}
}
接下来，我们看类的继承中，多态是如何体现的。
假如有一天，儿子穿着父亲的衣服到他老子的单位里去玩耍。如果这个时候，他老子的同事请他去钓鱼，这个是不行的，因为他到底的爱好是LOL，如果强行调用了play方法，就会露馅。
现在，假设他老子有一个吃饭的方法，喜欢吃水煮鱼，这一点，他儿子也是如此，所以，就不需要重写这个方法。
public class Fu {
public void eat(){
System.out.println("我正在吃饭，吃水煮鱼！");
}
public void play(){
System.out.println("钓鱼");
}
}
那么，如果他儿子跟他老子的同事一起去吃饭，并且吃了水煮鱼，就不会露馅。
假如下班后，他儿子去网咖玩“吃鸡”，但是衣服还没有来得及换。现在，儿子有吃鸡的方法：
public class Zi extends Fu{
public void play(){
System.out.println("LOL");
}
public void eatChicken(){
System.out.println("大吉大利，今晚吃鸡！");
}
}
当他去了网吧，强行调用自己的吃鸡方法。
竟然报错了！！！
因为现在他对外的身份还是父亲，而父亲是没有吃鸡的方法的，所以无法调用了。
于是啊，他一气之下，在网咖里脱衣服，回归自己的原来身份！
public class Test04 {
public static void main(String[] args) {
Fu f = new Zi();
((Zi) f).eatChicken(); //强制转换
}
}
总结：
多态就是，子类继承父类后，用父类型 new出自己的实例对象。就好比刚才例子中，儿子穿着他老子的衣服去他老子的公司做一些不可描述的事情。那些他老子没有，但是他没有的方法，不能使用，除非强制转换为子类的身份。
接着我们来演示一下类实现接口。
/**
* 游泳的能力 接口
* @author Administrator
*
*/
public interface Swimming {
public void goSwimming();
}
/**
* 飞行能力的接口
* @author Administrator
*
*/
public interface Fly {
public void goFlying();
}
让子类去实现游泳接口，表示其已经拥有了游泳的能力，和类的继承不同，如果一个类实现了某一个接口，就必须重写接口内所有的方法。
public class Zi extends Fu implements Swimming{
public void play(){
System.out.println("LOL");
}
public void eatChicken(){
System.out.println("大吉大利，今晚吃鸡！");
}
@Override
public void goSwimming() {
System.out.println("我已使出洪荒之力来游泳！");
}
}
编写一个飞鸟类，实现这个飞行的接口：
public class Bird implements Fly{
@Override
public void goFlying() {
System.out.println("I can Fly , can you ?");
}
}
那么，多态的体现就是，我们可以用接口类型去new出所有实现该接口的子类对象。
我们发现，new出来的子类对象除了Object类中方法之外，只能调用接口里的方法，不能调用自己的方法。就连他继承自父类的方法也不能调用！！
看到这里，大家可能会困惑，说这个多态有什么好，多态了之后，自己的方法好多都访问不了了！
在实际的项目开发中，多态更多的用处就是方便传参，就像上一篇文章中的例子一样，大乔在设计的时候，大招方法根本不知道你要传进来什么英雄，所以权宜之下，就设置参数为所有英雄的父类。
回到最初的问题，为什么要多态？
所以我个人认为多态更多的就是一种开发上的权宜之计，因为我们在编写一个统一的接口时，考虑不到那么多，只能大致的预留一个参数，这个参数当时可能是一个单独的类，也可能已经是一些子类的父类。可是在当时的情况下，我还并不知道这个项目后期会出现哪些重大的变化，会增加哪些新的功能？也许，随着项目的壮大，会出现越来越多的子类，我设计的方法也可能在某一天无法满足项目的需求。
如果那时我已经离职不在之前的公司，后续的程序员看到我的代码也不会去修改，最多就是继承一下我的类，然后重写或者重载我的方法。
因为谁也不敢保证自己改动原先的代码会不会引起项目的不稳定，所以一般都是继承后重新写。
后期有机会的话我会考虑专门写一个例子来说明这个事情。
