通常情况下,一个Java代码文件只定义一个类,即使两个类是父类与子类的关系,也要把它们拆成两个代码文件分别定义.可是有些事物相互之间密切联系,又不同于父子类的继承关系,比如一棵树会开很多花朵,这些花儿作为树木的一份子,它们依附于树木,却不是树木的后代.花朵不但拥有独特的形态,包括花瓣.花蕊.花萼等,而且拥有完整的生命周期,从含苞欲放到盛开绽放再到凋谢枯萎.这样一来,倘若把花朵抽象为花朵类,那么花朵类将囊括花瓣.花蕊.花萼等成员属性,以及含苞.盛开.凋谢等成员方法.既然花朵类如此规整,完全可以定义…
不管是基本的char字符型,还是包装字符类型Character,它们的每个变量只能存放一个字符,无法满足对一串字符的加工.为了能够直接操作一连串的字符,Java设计了专门的字符串类型String,该类型允许保存一整串字符,并对字符串进行各种处理.字符串类型不属于基本类型,它的用法与包装类型更为接近.例如给字符串变量赋初始值,就有多达四种的赋值形式(包装类型只有三种赋值),分别介绍如下:1.被双引号包裹着的字符串,可直接用等号赋值给字符串变量,代码示例如下: // 第一种方式:用双引号把字符串括起…
前面介绍子类继承父类的时候,提到了public(公共)和private(私有)两个修饰符,其中public表示它所修饰的实体是允许外部访问的:而private表示它所修饰的实体不允许外部访问,只能在当前类内部访问private成员,即便是子类也不能访问父类的私有成员.这种情况就令人产生了困惑,私人财产当然不会给外人,可是为啥连儿子都无法动用老子的财物呢?看起来public与private的规则不甚合理,毕竟儿子同外人还是有区别的呀,所谓亲疏有别.一家人不说两家话.为此Java设计了新的修饰符名叫…
前面介绍了联合利用final和static可实现常量的定义,该方式用于简单的常量倒还凑合,要是用于复杂的.安全性高的常量,那就力不从心了.例如以下几种情况,final结合static的方式便缺乏应对之策:1.虽然常量的名称以大写字母拼写,但是对应的取值基本为1.2.3之类的整数,如果把1.2.3直接写在调用的代码里面,岂不是浑水摸鱼顶替了现有的常量蒙混过关?2.代码可以从常量名推出对应的常量值,可是反过来并不能从常量值推出对应的常量名,开发者晓得不代表程序也晓得.3.每个常量只有唯一的数值表达,…
程序除了处理内存中的数据结构,还要操作磁盘上的各类文件,这里的磁盘是个统称,泛指可以持久保留数据的存储介质,包括但不限于:插在软驱中的软盘.固定在机箱中的硬盘.插在光驱中的光盘.插在USB接口上的U盘.笔记本电脑里的固态盘.手机中的闪存.相机里的SD卡等等.当然,操作系统层面已经统一了这些存储介质,故而编程语言无须理会它们之间的区别,只需专心访问存储介质上保存的文件.为表述方便,接下来将用"磁盘"二字代指以上罗列的各种存储介质.Java使用File工具来操作磁盘文件,只要在构造方法中填…
经过前面的学习,我们发现演示的Java代码越来越复杂,而且每个例子的代码都堆在入口方法main内部,这会导致如下问题:1.一个方法内部堆砌了太多的代码行,看着费神,维护起来也吃力:2.部分代码描述的是通用算法,比如牛顿迭代法.二分查找法等等,这些通用的算法代码结构固定,很多地方会用到,倘若每次都复制粘贴无疑是苦大仇深:基于此,亟需对纷繁复杂的代码段加以梳理,一方面把代码行依据功能进行划分,这样剥离出来的各段代码不会相互影响:另一方面封装通用的算法代码,做到只定义一次,就能被多次调用.这样既提高了…
前面介绍了类的多态性,来自于鸡类的实例chicken,既能用来表达公鸡实例,也能用来表达母鸡实例.可是这导致了一个问题,假如在call方法内部需要手工判断输入参数属于公鸡实例还是母鸡实例,那该如何是好?所谓“雄兔脚扑朔,雌兔眼迷离,双兔傍地走,安能辨我是雄雌”,固然编译器在运行之时能够自动判断这是哪种鸡,可是若让程序员自己辨别倒的确是件伤脑筋的事情.虽说伤脑筋,却也并非无法实现,粗略算来大致有三个办法能派上用场,接下来分别进行阐述.第一个办法,区别公鸡和母鸡,关键在于识别鸡的性别.注意到Chic…
前面介绍嵌套类的时候讲到了关键字static,用static修饰类,该类就变成了嵌套类.从嵌套类的用法可知,其它地方访问嵌套类之时,无需动态创建外层类的实例,直接创建嵌套类的实例就行.其实static不光修饰类,还能用来修饰方法.修饰属性等等,例如大家学习Java一开始就遇到的main方法,便为static所修饰.当一个成员方法被static修饰之后,该方法就成为静态方法:当一个成员属性被static修饰之后,该属性就成为静态属性.静态方法和静态属性,它俩同嵌套类一样不依赖于所在类的实例.外部若…
前面介绍了抽象方法及抽象类的用法,看似解决了不确定行为的方法定义,既然叫唤动作允许声明为抽象方法,那么飞翔.游泳也能声明为抽象方法,并且鸡类涵盖的物种不够多,最好把这些行为动作扩展到鸟类这个群体,于是整个鸟类的成员方法都可以如法炮制了.可是这种做法也带来了一些弊端,包括但不限于:1.能飞的动物不仅仅是鸟类,还有昆虫.蝙蝠等其它动物也能飞,难不成昆虫类.哺乳动物类也要自行声明飞翔方法?这么做显然产生了重复的方法定义.不然的话,要是把飞翔方法挪到更底层的动物类,一大群动物为了不沦为抽象类都得重写飞翔…
前面介绍了接口的基本用法,有心的朋友可能注意到这么一句话“在Java8以前,接口内部的所有方法都必须是抽象方法”,如此说来,在Java8之后,接口的内部方法也可能不是抽象方法了吗?之所以Java8对接口的定义规则发生变化,是因为原来的接口定义存在先天不足导致的,例如下列几点需求就难以满足:1.Java8以前规定接口的内部方法只能是抽象方法,在该接口的实现类里面全部都要重写.这个规定明显太霸道了,为什么非得所有都重写呢?有的行为分明是通用的,比如呼吸动作,凡是陆上动物都用鼻子呼吸,把新鲜空气吸进去…