专栏首页Jack的Android之旅疯狂Java笔记之面向对象的陷阱

疯狂Java笔记之面向对象的陷阱

instanceof运算符的陷阱

instanceof是一个非常简单的运算符。instanceof运算符的前一个操作数通常是一个引用类型的变量,后一个操作数通常是一个类(也可以是接口,可以把接口理解成一个特殊的类),他用于判断前面的对象是否是后面的类或其子类,实现类的实例。如果是,则返回true,否则,返回false.

String obj="Java";
obj instanceof Math

上面程序是无法编译通过的,根据Java语言规范,使用instanceof运算符有一个限制:instanceof运算符前面操作数的编译时类型必须是如下三种情况。

  • 要么与后面的类相同
  • 要么与后面类的父类
  • 要么是后面类的子类

如果前面操作数的编译时类型与后面的类型没有任何关系,程序将没法用过编译。因此,当使用instanceof运算符的时候,应尽量从编译,运行两个阶段来考虑它————如果instanceof运算符使用不当,程序编译时就会抛出异常;当使用instanceof运算符用过编译后,才能考虑它的运算结果是true,还是false.

在极端情况下,instanceof前一个操作数所引用对象的实际类型就是后面的类型,但只要它的编译时类型既不是第二个操作数的类型, 也不是第二个操作数的父类,子类程序就没法通过编译。如下:

Object str="java";
Math math=(Math)str;
System.out.println("字符串是否是String的实例:"+(math instanceof String));()

当编译器编译java程序时,编译器无法检查引用变量实际引用对象的类型,他只检查该变量的编译时类型。最后一句代码math的编译时类型是Math,Math既不是String类型,也不是String类型的父类,还不是String类型的子类,因此程序没法通过编译。至于math实际引用对象的类型是什么,编译器也不关心,编译阶段也没法关心。

至于第二行代码为何没有出现编译错误,这和强制转型机制有关。对于Java的强制转型而言,也可以分为编译,运行两个阶段来分析它。

  • 在编译阶段,强制转型要求被转型变量的编译时类型必须是如下三种情况之一.
  1. 被转型变量的编译时类型与目标类型相同。
  2. 被转型变量的编译时类型是目标类型父类。
  3. 被转型变量的编译时类型是目标类型子类。在这个情况下可以自动向上转型,无须强制转换。 如果被转型变量的编译时类型与目标类型没有任何继承关系,编译器将提示编译错误。通过上面分析可以看出,强制转型的编译阶段只关心引用变量的编译时类型,至于该引用变量实际引用对象的类型,编译器并不关心,也没法关心。
  • 在运行阶段,被转型变量所引用对象的实际类型必须是目标类型的实例,或者是目标类型的子类、实现类的实例,否则在运行时将引发ClassCastExceptivn异常。
String s=null;
System.out.println(s instanceof String);

使null调用instanceof运算符时返回false是非常有用的行为,因为instanceof运算符有了一个额外的功能:它可以保证第一个操作数所引用的对象不是null如果instanceof告知一个引用变量是某个特定类型的实例,那么就可以将其转型为该类型,并调用该类型的方法,而不用担心会抛出ClassGastExeception或NullPointerException异常。

构造器的陷阱

构造器创建对象吗

实际上构造器井不会创建Java对象,构造器只是负责执行初始化,在构造器执行之前,Java对象所需要的内存空间,应该说是由new关键字中请出来的。

绝大部分时候,程序使用new关键字为一个Java对象申请空间之后,都需要使用构造器为这个对象执行初始化。但在某些时候,程序创建Java对象无须调用构造器,以下面两种方式创建的Java对象无须使用构造器。

  • 使用反序列化的方法恢复java对象。
  • 使用clone方法复制java对象。

无限递归的构造器

public class Main {
    Main main;
    {
        main=new Main();
    }

    public Main(){
        System.out.println("执行构造器");
    }

    public static void main(String[] args) {
        Main main=new Main();
    }
}

不管是定义实例变量是指定的初始值,还是在非静态初始化块中执行的初始化操作,最终都将被提取到构造器中执行。所以以上代码到时了构造器递归。

这个程序给出的教训是,无论如何不要导致构造器产生递归调用。也就是说,应该:

  • 尽量不要在定义实例变量时指定实例变量的值为当前类的实例。
  • 尽量不要在初始化块中创建当前类的实例口
  • 尽量不要在构造器内调用本构造器创建Java对象。

持有当前类的实例

对于一个java类而言,他的一个实例持有当前类的另一个实例是被允许的,只要程序初始化它持有当前类的实例时不会引起构造器递归就行。

public class Main {
   private String name;
   private Main instance;
   public Main(){

   }
   public Main(String name){
       instance=new Main();
       instance.name=name;
   }
   public static void main(String[] args){
       Main main=new Main();
       Main main2=new Main("测试");
   }
}

到底调用哪个重载的方法

public class Main {
    public void info(Object obj,double count){
        System.out.println("obj:"+obj);
        System.out.println("count:"+count);
    }
    public void info(Object[] objs,double count){
        System.out.println("objs:"+objs);
        System.out.println("count:"+count);
    }
    public static void main(String[] args){
        Main main=new Main();
        main.info(null,5);
    }
}

上面代码方法的调用看似info(Object[],int)和info(Obejct,int)都是可以匹配的,那到底调用哪个呢。

根据精确匹配原则,当实际调用是传入的实参满足多个方法时,如果某个方法的形参要求参数范围越小,那么这个方法就越精确。很明显,Object[]可以看成Object的子类,info(Object[] ,int)方法匹配的更精确,执行上面程序,将看到如下输出:

objs:null
count:5.0

再看一个极端的例子:

public class Main {
    public void info(Object obj,int count){
        System.out.println("obj:"+obj);
        System.out.println("count:"+count);
    }
    public void info(Object[] objs,double count){
        System.out.println("objs:"+objs);
        System.out.println("count:"+count);
    }
    public static void main(String[] args){
        Main main=new Main();
        main.info(null,5);
    }
}

调用方法时第一个参数调info(Object[] objs,double count)比较好,而第二个参数调info(Obejct obj,int count)比较好,而两个参数中和就不知道了。所以系统报错。

方法重写的陷阱

对于使用private修饰符修饰的方法,只能在当前类中访问该方法,子类无法访问父类中定义的private方法。既然子类无法访问父类的private。方法,当然也就无法重写该方法。

如果子类中定义了一个与父类的private方法具有相同的方法名、相同的形参列表、相同的返回值类型的方法,依然不是重写,只是了类中重新定义了一个新方法。

重写其他访问权限的方法

如果父类中定义了使用默认访问控制符(也就是不使用访问控制符)修饰方法,这个方法同样可能无法被重写。

对于不使用访问控制符修饰的方法,它只能被与当前类处于同一个包中的其他类访问,其他包中的子类依然无法访问该方法。只有与当前类处于同一个包中的其他类才能访问该方法。

非静态内部类的陷阱

非静态内部类的构造器

非静态内部类必须寄生在外部类实例中,没有外部类的对象,就不可能产生非静态内部类的对象。因此,非静态内部类不可能有无参数的构造器————即是系统为非静态内部类提供一个默认的构造器,这个默认的构造器也需要一个外部类形参。

系统在编译阶段总会为非静态内部类的构造器增加一个参数,非静态内部类的构造器的第一个形参总是外部类。因此调用非静态内部类的构造器时必须传入一个外部类对象作为参数,否则程序将会引发运行时异常。

非静态内部类不能拥有静态成员

对于非静态内部类而言,由于它本身就是一个非静态的上下文环境,因此非静态内部类不允许拥有静态成员。

非静态内部类的子类

由于非静态内部类没有无参数的构造器,因此通过非静态内部类派生子类时也可能存在一些陷阱。

class Base{
  class In{
      public void test(){
          System.out.println("In的Test方法");
      }
  }
  class A extends In{

  }
}
public class sub extends Base.In{
    public sub(){

    }
    public static void main(String[] args){
        System.out.println("Hello World");
    }
}

由于非静态内部类In必须寄生在Base对象之内,因此父类Base.In根本没有参数的构造器。而程序定义其子类Base.In时,没有定义构造器,那么系统会为它提供一个无参数的构造器。在sub无参数的构造器内,编译器会增加代码super()————子类总会调用父类的构造器。对于这个super()调用,指定调用父类Base.In无参数的构造器,必然导致编译错误.为了解决这个问题,应该为sub显示定义一个构造器,在该构造器中显示调用Base.In父类对应的构造器。

public class sub extends Base.In{
    public sub(){
        new Base().super();
    }
    public static void main(String[] args){
        System.out.println("Hello World");
    }
}

以上显式的调用父类的构造器。使用new Base()作为主调————即以一个Base对象作为主调,其实这个主调会作为参数擦传入super(),也就是传给In类带一个Base参数的构造器。

static关键字

静态方法属于类

被static关键字修饰的成员(Field,方法,内部类,初始化块,内部枚举类)属于类本身,而不是当个的java对象,具体到静态方法也是如此,静态方法属于类。而不属于Java对象。

静态内部类的限制

当程序使用内部类时,应尽量考虑使用静态内部类,而不是非静态内部类。当程序使用静态内部类时,外部类相当于静态内部类的一个包,因此使用起来比较方便;但另一方面,这也给静态内部类增加了一个限制———静态内部类不能访问外部类的非静态成员。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 疯狂Java笔记之对象及其内存管理

    类体内定义的变量被称为成员变量〔英文是Field)。如果定义该成员变量时没有使用static 修饰,该成员变量又被称为非静态变量或实例变量;如果使用了stat...

    HelloJack
  • React Native与Android 原生通信

    我们用React Native 做混合开发的时候免不了要原生和React Native 进行通信交互,这篇文章就是分享原生模块与JS传递数据的几种方式。

    HelloJack
  • Android NestedScrolling机制

    NestedScrolling机制现在在App的作用越来越重要,许多很漂亮的交互都是基于NestedScrolling机制进行完成的。

    HelloJack
  • SpringBoot Web篇(二)

    当我们服务器需要接收用户上传的文件时,就需要使用MultipartFile作为参数接收文件。如下:

    Johnson木木
  • 消息中间件系列第3讲:使用消息队列需要考虑的几个问题

    放在消息队列中,消息幂等性的意思是:一条完全一样的消息,它消息一次和消费无数次的结果是一样的。

    陈树义
  • 不懂这12个语法糖,别说你会Java!

    本文从 Java 编译原理角度,深入字节码及 class 文件,抽丝剥茧,了解 Java 中的语法糖原理及用法,帮助大家在学会如何使用 Java 语法糖的同时,...

    纯洁的微笑
  • 不懂这12个语法糖,别说你会Java!

    本文从 Java 编译原理角度,深入字节码及 class 文件,抽丝剥茧,了解 Java 中的语法糖原理及用法,帮助大家在学会如何使用 Java 语法糖的同时,...

    Java技术江湖
  • 不了解这 12 个语法糖,别说你会 Java!

    本文从 Java 编译原理角度,深入字节码及 class 文件,抽丝剥茧,了解 Java 中的语法糖原理及用法,帮助大家在学会如何使用 Java 语法糖的同时,...

    Java技术江湖
  • 【一起学系列】之装饰器模式:不改代码增强功能?

    动态地给一个对象添加一些额外的职责,就增加功能来说,Decorator模式相比生成子类更为灵活

    Kerwin
  • 在Java中12个常见的语法糖!

    本文从 Java 编译原理角度,深入字节码及 class 文件,抽丝剥茧,了解 Java 中的语法糖原理及用法,帮助大家在学会如何使用 Java 语法糖的同时,...

    Java3y

扫码关注云+社区

领取腾讯云代金券