継承、およびJavaのような言語でのメンバー/属性およびメソッドへの動的アクセス

JavaのようなOOプログラミング言語での継承について質問があります。メソッドとその呼び出しをコンパイルする方法を説明したとき、それは私のコンパイラクラスで思い付きました。コンパイルするソース言語の例としてJavaを使用していました。

次に、このJavaプログラムについて考えてみましょう。

class A {
  public int x = 0;
  void f () { System.out.println ( "A:f" ); } }

class B extends A {
  public int x = 1;
  void f () { System.out.println ( "B:f" ); } }

public class Main {
  public static void main ( String [] args ) {
    A a = new A ();
    B b = new B ();
    A ab = new B ();

    a.f();
    b.f();
    ab.f();
    System.out.println ( a.x );
    System.out.println ( b.x );
    System.out.println ( ab.x ); } }

実行すると、次の結果が得られます。

A:f
B:f
B:f
0
1 
0

興味深いのは、動的abなstatic型のオブジェクトで発生するケースです。プリントアウトとしてABab.f()

B:f

つまり、メソッドの呼び出しは、メソッドの呼び出しに使用されたオブジェクトのコンパイル時のタイプの影響を受けません。ただし、が System.out.println ( ab.x )出力される0ため、メンバーアクセスはコンパイル時の型の影響を受けます。

学生はこの違いについて質問しました：メンバーのアクセス方法とメソッドは互いに一致してはいけませんか？「それがJavaのセマンティクスだ」よりも良い答えを思いつくことができませんでした。

メンバーとメソッドがこの意味で異なるのは、はっきりとした概念的な理由を知っていますか？生徒に何か教えてもらえますか？

編集：さらなる調査の結果、これはJavaの特異性のようです：C ++とC＃の動作は異なります。たとえば、以下のSaeed Amiriのコメントを参照してください。

編集2：対応するScalaプログラムを試してみました。

class A {
  val x = 0;
  def f () : Unit = { System.out.println ( "A:f" ); } }

class B extends A {
  override val x = 1;
  override def f () : Unit = { System.out.println ( "B:f" ); } }

object Main {
  def main ( args : Array [ String ] ) = {
    var a : A = new A ();
    var b : B = new B ();
    var ab : A = new B ();
    a.f();
    b.f();
    ab.f();
    System.out.println ( "a.x = " + a.x );
    System.out.println ( "b.x = " + b.x );
    System.out.println ( "ab.x = " + ab.x ); } }

そして驚いたことに、これは

A:f
B:f
B:f
a.x = 0
b.x = 1
ab.x = 1

overrise修飾子が必要であることに注意してください。ScalaはJVMにコンパイルされ、さらに、Scalaコンパイラ/ランタイムを使用してJavaプログラムを最上部でコンパイルおよび実行すると、Javaプログラムのように動作するので、これは私を驚かせます。

これはJavaのフィールドのシャドウイングと密接に関連していると思います。

派生クラスを書くとき、あなたの例のように、基本クラスののx定義を隠すフィールドを書くことができますx。つまり、派生クラスでは、元の定義にはnameを介してアクセスできなくなりますx。Javaがこれを許可しているのは、派生クラスの実装が基本クラスの実装の詳細にあまり依存しないため、脆弱な基本クラスの問題が（部分的にのみ）回避されるためです。たとえば、基本クラスに元々フィールドがなかったxが、その後にフィールドが導入された場合、Javaのセマンティクスは、これが派生クラスの実装を壊すことを避けます。

変数x派生クラスでは、基本クラス内の変数とは完全に異なる型を持つことができます-私はこれをテストし、それが動作します。これは、型が十分に互換性がある必要がある（別名、同じ）メソッドのオーバーライドとはまったく対照的です。したがってA、あなたの例にタイプの変数がある場合、派生できる唯一のタイプは、クラスA（またはそれ以上）で指定されたタイプです。これはクラスBで宣言されたタイプとは異なる場合があるためx、クラスからフィールドの値を返すのはタイプセーフのみAです。（当然のことながら、クラスのフィールドのタイプに関係なく、セマンティクスは同じでなければなりませんB。）

Javaでは、「オブジェクトの静的タイプ」はありません-オブジェクトのタイプがあり、参照のタイプがあります。すべてのJavaメソッドは「仮想」（C ++の用語を使用するため）です。つまり、オブジェクトのタイプに基づいて解決されます。そしてところで。'@Override'は、コンパイルされたコードにはまったく影響を与えません。注釈が付けられたメソッドがスーパークラスのメソッドをオーバーライドしない場合、コンパイラエラーを生成するのは単なる保護手段です。

一方、フィールドアクセスが動的に解決されることはありません。言い換えると、Javaはフィールドにアクセスするときにポリモーフィズムを使用しません。サブクラスにスーパークラスフィールドと同じ名前のフィールドxがある（病理学的）場合、サブクラスには2つのフィールド 'x'があります。明らかに、名前のシャドーイングがあります。名前「x」は、特定のコンテキストでこれらのフィールドの1つにのみバインドできます。

名前解決構文を入力 します-bxを書き込むと、コンパイラーはこれをサブクラスで宣言されたフィールドに解決しますが、ab.xを書き込むと、コンパイラーはそれをAで宣言されたフィールドに解決します-両方のフィールドはクラスBのメンバーです。 super.xを使用して、クラスBのコードから両方のフィールドにアクセスできます。

クラスB {... void g（）{System.out.println（ "both：" + x + "and" + super.x）;}}

したがって、実行時に、サブクラスフィールドの名前が「x」でも「y」でも、違いはありません。どちらの場合も、サブクラスには2つの異なるフィールドがあり、それらの間に関係はありません。

継承はB"is a"の形式であることを思い出してくださいA。ただし、機能Aが拡張される可能性がある場合を除き、継承されたメンバー変数はオブジェクトの属性と見なすことができます。直感的に、継承について教えられた方法（確かにJava風の観点から）、メンバー変数は属性のようなものであり、共通の属性は拡張されることを意図しておらず、機能だけが拡張されています。

たとえば、Personクラスがあり、人物に名前変数があるとします。とに拡張Personしても、名前は直感的に変更されません。ただし、たとえば「宿題」を行うために、メソッドは拡張されますが、クラスではでテストを採点する場合があります。StudentProfessorStudent.do_work()ProfessorProfessor.do_work()

もちろん、この直感を壊すことができ、メンバー変数をプロパティと同等にしたり、オーバーライドできるゲッターを使用したりすることができますが、私が上で言ったことは、このようにすることの直感だったと思います。実際、派生クラスで同じ名前のメンバー変数を使用することは、ほとんどの場合型破りだと思います。