Java构造函数不是那么直观。也许不是Java,不是直观的C# - c#

给定此Java代码,将输出 0和4 :

class A{
   A() {  print();   }
   void print() { System.out.println("A"); }
}

class B extends A{
   int i =   Math.round(3.5f); 

   public static void main(String[] args){
      A a = new B();
      a.print();
   }
   void print() { System.out.println(i); }
}

并使用相同的C#代码输出 4和 4

使用系统;

class A{
   internal A() {  print();   }
   virtual internal void print() { Console.WriteLine("A"); }
}

class B : A{
   int i =  (int) Math.Round(3.5f); 

   public static void Main(string[] args){
      A a = new B();
      a.print();
   }
   override internal void print() { Console.WriteLine(i); }
}

尽管我发现在Java上输出应该是4和4,但是答案实际上在Java上是0和4。然后我在C#中尝试了,答案是4和4

是什么赋予了? Java的基本原理是,在B的构造过程中,A仍在初始化(因此,如果Java表示A仍在初始化,则B位置仍在初始化),因此默认值应为0。因此在Java中输出为0和4。

为什么C#构造函数的行为不同于Java,反之亦然?

参考方案

之所以发生这种情况,是因为构造函数中对象初始化的顺序不同。

Java中发生了什么:

  • (空,隐式)B的构造函数称为
  • 称为

  • A的超类构造函数(由于未初始化,所以打印0)
  • 我在超类构造函数
  • 之后初始化

  • print()被称为(打印4)
  • C#中发生了什么:

  • (空,隐式)B的构造函数称为
  • 我在调用超类构造函数
  • 之前进行了初始化
    称为A的

  • A超类构造函数(由于我已经初始化,因此打印4)
  • print()被称为(打印4)
  • 对与错都没有-这只是编译器命令构造操作的方式不同。我个人认为Java排序稍微有点逻辑,因为对我来说,在子类初始化发生之前就已经完全构建了超类,这对我来说很有意义。

    无论哪种方式,由于逻辑都会变得非常复杂,因此建议您通常避免在对象构建期间调用虚拟方法。

    Java-了解递归 - java

    有人可以向我解释为什么打印出来1 2 3 4 5吗?我认为它将打印出4 3 2 1 0,但是我的书和日食都说我错了。public class whatever { /** * @param args */ public static void main(String[] args) { xMethod(5); } public static void xMe…

    Java:正则表达式模式匹配器是否有大小限制? - java

    我的模式类似于OR:“word1 | word2 | word3”我大约有800个字。可能有问题吗? 参考方案 您仅受记忆和理智的限制。 :)

    Java:线程池如何将线程映射到可运行对象 - java

    试图绕过Java并发问题,并且很难理解线程池,线程以及它们正在执行的可运行“任务”之间的关系。如果我创建一个有10个线程的线程池,那么我是否必须将相同的任务传递给池中的每个线程,或者池化的线程实际上只是与任务无关的“工人无人机”可用于执行任何任务?无论哪种方式,Executor / ExecutorService如何将正确的任务分配给正确的线程? 参考方案 …

    JAVA:字节码和二进制有什么区别? - java

    java字节代码(已编译的语言,也称为目标代码)与机器代码(当前计算机的本机代码)之间有什么区别?我读过一些书,他们将字节码称为二进制指令,但我不知道为什么。 参考方案 字节码是独立于平台的,在Windows中运行的编译器编译的字节码仍将在linux / unix / mac中运行。机器代码是特定于平台的,如果在Windows x86中编译,则它将仅在Win…

    java:继承 - java

    有哪些替代继承的方法? java大神给出的解决方案 有效的Java:偏重于继承而不是继承。 (这实际上也来自“四人帮”)。他提出的理由是,如果扩展类未明确设计为继承,则继承会引起很多不正常的副作用。例如,对super.someMethod()的任何调用都可以引导您通过未知代码的意外路径。取而代之的是,持有对本来应该扩展的类的引用,然后委托给它。这是与Eric…