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

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

江湖上传闻,面向对象之所以厉害,是因为它拥有封装.继承与多态三项神技,只要三板斧一出,号令天下谁敢不从.前面费了老大的劲才讲清楚封装和继承,那么多态又是怎样的神乎其神呢?下面先通过一个简单的例子来说明多态的使用场景.首先把鸡这种家禽通过面向对象来表达,方便起见只定义两个属性(名称和性别),以及一个call方法,定义好的鸡类代码如下所示: //定义一个鸡类 public class Chicken { // 定义一个名称属性 public String name; // 定义一个性别属性 publ…

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

前面介绍了多态的相关用法,可以看到一个子类从父类继承之后,便能假借父类的名义到处晃悠.这种机制在正常情况之下没啥问题,但有时为了预防意外发生,往往只接受当事人来处理,不希望它的儿子乃至孙子来瞎掺和.可是犹记得几种开放性修饰符,只能控制某个实体能否被外部访问,从未听说可决定某个类能否被其它类所继承.毫无疑问,是否开放与能否继承是两种不同的概念,不管是被public修饰的公共类,还是被private修饰的私有类,它们默认都是允许继承的.要想让某个类不能被其它类继承,还得在类名前面额外添加一个关键字f…

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

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

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

前面介绍了类的常见用法,令人感叹面向对象的强大,几乎日常生活中的所有事物,都可以抽象成Java的基类及其子类.然而抽象操作也有副作用,就是某个抽象而来的行为可能是不确定的,比如半夜鸡叫,如果是公鸡则必定“喔喔喔”地叫,如果是母鸡则必定“咯咯咯”地叫,可要是不能确定这只鸡是公鸡还是母鸡抑或小鸡,系统怎么知道它会怎么叫?落实到鸡类Chicken的定义代码中,它的call方法便无法给出具体的叫声了,尽管鸡类能够派生出公鸡类和母鸡类,再在公鸡类和母鸡类重写call方法,但是外部仍然可以创建鸡类的实例,接…

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