前面介绍了类的多态性,来自于鸡类的实例chicken,既能用来表达公鸡实例,也能用来表达母鸡实例.可是这导致了一个问题,假如在call方法内部需要手工判断输入参数属于公鸡实例还是母鸡实例,那该如何是好?所谓“雄兔脚扑朔,雌兔眼迷离,双兔傍地走,安能辨我是雄雌”,固然编译器在运行之时能够自动判断这是哪种鸡,可是若让程序员自己辨别倒的确是件伤脑筋的事情.虽说伤脑筋,却也并非无法实现,粗略算来大致有三个办法能派上用场,接下来分别进行阐述.第一个办法,区别公鸡和母鸡,关键在于识别鸡的性别.注意到Chic…

Java的注解非但是一种标记,还是一种特殊的类型,并且拥有专门的类型定义.前面介绍的五种内置注解,都可以找到对应的类型定义代码,例如查看注解@Override的源码,发现它的代码定义是下面这样的: @Target(ElementType.METHOD) @Retention(RetentionPolicy.SOURCE) public @interface Override {} 又如注解@FunctionalInterface,它的源码定义与之类似: @Documented @Retentio…

前面提到字符类型是一种新的变量类型,然而编码实践的过程中却发现,某个具体的字符值居然可以赋值给整型变量!就像下面的例子代码那样,把字符值赋给整型变量,编译器不但没报错,而且还能正常运行! // 字符允许直接赋值给整型变量 private static void charToInt() { int a = 'A'; System.out.println("int a="+a); int tian = '田'; System.out.println("int tian="…

前面介绍了日历工具Calendar的基本用法,乍看起来Calendar与Date两个半斤八两,似乎没有多大区别,那又何苦庸人自扰鼓捣一个新玩意呢?显然这样小瞧了Calendar,其实它的作用大着呢,接下来不妨深入探讨一下Calendar的几种实际应用,主要包括:Calendar和Date类型互相转换.计算两个日历时间的天数.打印当前月份的月历等,分别说明如下. 1.Calendar和Date类型互相转换虽说Date早就应该被Calendar取代,但毕竟是前辈,而且Java也一直没有抛弃它,特别有…

前面介绍子类继承父类的时候,提到了public(公共)和private(私有)两个修饰符,其中public表示它所修饰的实体是允许外部访问的:而private表示它所修饰的实体不允许外部访问,只能在当前类内部访问private成员,即便是子类也不能访问父类的私有成员.这种情况就令人产生了困惑,私人财产当然不会给外人,可是为啥连儿子都无法动用老子的财物呢?看起来public与private的规则不甚合理,毕竟儿子同外人还是有区别的呀,所谓亲疏有别.一家人不说两家话.为此Java设计了新的修饰符名叫…

前面介绍了联合利用final和static可实现常量的定义,该方式用于简单的常量倒还凑合,要是用于复杂的.安全性高的常量,那就力不从心了.例如以下几种情况,final结合static的方式便缺乏应对之策:1.虽然常量的名称以大写字母拼写,但是对应的取值基本为1.2.3之类的整数,如果把1.2.3直接写在调用的代码里面,岂不是浑水摸鱼顶替了现有的常量蒙混过关?2.代码可以从常量名推出对应的常量值,可是反过来并不能从常量值推出对应的常量名,开发者晓得不代表程序也晓得.3.每个常量只有唯一的数值表达,…

通常情况下,一个Java代码文件只定义一个类,即使两个类是父类与子类的关系,也要把它们拆成两个代码文件分别定义.可是有些事物相互之间密切联系,又不同于父子类的继承关系,比如一棵树会开很多花朵,这些花儿作为树木的一份子,它们依附于树木,却不是树木的后代.花朵不但拥有独特的形态,包括花瓣.花蕊.花萼等,而且拥有完整的生命周期,从含苞欲放到盛开绽放再到凋谢枯萎.这样一来,倘若把花朵抽象为花朵类,那么花朵类将囊括花瓣.花蕊.花萼等成员属性,以及含苞.盛开.凋谢等成员方法.既然花朵类如此规整,完全可以定义…

前面介绍嵌套类的时候讲到了关键字static,用static修饰类,该类就变成了嵌套类.从嵌套类的用法可知,其它地方访问嵌套类之时,无需动态创建外层类的实例,直接创建嵌套类的实例就行.其实static不光修饰类,还能用来修饰方法.修饰属性等等,例如大家学习Java一开始就遇到的main方法,便为static所修饰.当一个成员方法被static修饰之后,该方法就成为静态方法:当一个成员属性被static修饰之后,该属性就成为静态属性.静态方法和静态属性,它俩同嵌套类一样不依赖于所在类的实例.外部若…

前面介绍了抽象方法及抽象类的用法,看似解决了不确定行为的方法定义,既然叫唤动作允许声明为抽象方法,那么飞翔.游泳也能声明为抽象方法,并且鸡类涵盖的物种不够多,最好把这些行为动作扩展到鸟类这个群体,于是整个鸟类的成员方法都可以如法炮制了.可是这种做法也带来了一些弊端,包括但不限于:1.能飞的动物不仅仅是鸟类,还有昆虫.蝙蝠等其它动物也能飞,难不成昆虫类.哺乳动物类也要自行声明飞翔方法?这么做显然产生了重复的方法定义.不然的话,要是把飞翔方法挪到更底层的动物类,一大群动物为了不沦为抽象类都得重写飞翔…

前面介绍了接口的基本用法,有心的朋友可能注意到这么一句话“在Java8以前,接口内部的所有方法都必须是抽象方法”,如此说来,在Java8之后,接口的内部方法也可能不是抽象方法了吗?之所以Java8对接口的定义规则发生变化,是因为原来的接口定义存在先天不足导致的,例如下列几点需求就难以满足:1.Java8以前规定接口的内部方法只能是抽象方法,在该接口的实现类里面全部都要重写.这个规定明显太霸道了,为什么非得所有都重写呢?有的行为分明是通用的,比如呼吸动作,凡是陆上动物都用鼻子呼吸,把新鲜空气吸进去…