Kotlinバッキングフィールドとは何ですか？

Java開発者として、バッキングフィールドの概念は私には少し異質です。与えられた：

class Sample {
    var counter = 0 // the initializer value is written directly to the backing field
    set(value) {
        if (value >= 0) field = value
    }
}

このバッキングフィールドは何に適していますか？Kotlinのドキュメントによると：

Kotlinのクラスにフィールドを含めることはできません。ただし、カスタムアクセサを使用する場合は、バッキングフィールドが必要になる場合があります。

どうして？セッター内でプロパティ名自体を使用することとの違いは何ですか？例：*

class Sample {        
    var counter = 0
    set(value) {
        if (value >= 0) this.counter = value // or just counter = value?
    }
}

なぜなら、fieldキーワードがないと、get()またはの値を実際に設定/取得することができないからset(value)です。これにより、カスタムアクセサのバッキングフィールドにアクセスできます。

これは、サンプルと同等のJavaコードです。

class Sample {
    private int counter = 0;
    public void setCounter(int value) {
        if (value >= 0) setCounter(value);
    }
    public int getCounter() {
        return counter;
    }
}

セッターはそれ自体への無限の再帰であり、何も変更しないため、これは明らかに良くありません。kotlinでは、書き込むたびfoo.bar = valueに、ではなくセッター呼び出しに変換されることを忘れないでくださいPUTFIELD。

編集：Javaにはフィールドがあり、Kotlinにはプロパティがあります。これは、フィールドよりもかなり高いレベルの概念です。

プロパティには2つのタイプがあります。1つはバッキングフィールドあり、もう1つはバッキングフィールドなしです。

バッキングフィールドを持つプロパティは、フィールドの形式で値を格納します。このフィールドにより、値をメモリに保存できます。このようなプロパティの例は、のfirstおよびsecondプロパティですPair。そのプロパティは、のメモリ内表現を変更しPairます。

バッキングフィールドのないプロパティは、メモリに直接格納する以外の方法で値を格納する必要があります。他のプロパティ、またはオブジェクト自体から計算する必要があります。このようなプロパティの例は、のindices拡張プロパティですList。これは、フィールドに裏打ちされていませんが、sizeプロパティに基づいて計算された結果です。したがって、のメモリ内表現は変更されませんList（Javaは静的に型指定されているため、まったく変更できません）。

当初、私もこの概念を理解するのに苦労しました。それで、例の助けを借りてそれをあなたに説明させてください。

このKotlinクラスを検討してください

class DummyClass {
    var size = 0;
    var isEmpty
        get() = size == 0
        set(value) {
            size = size * 2
        }
}

コードを見ると、2つのプロパティ、つまり- size（デフォルトのアクセサーを使用）とisEmpty（カスタムアクセサーを使用）があることがわかります。ただし、フィールドは1つだけsizeです。フィールドが1つしかないことを理解するために、このクラスに相当するJavaを見てみましょう。

[ツール]-> [Kotlin]-> [AndroidStudioでKotlinByteCodeを表示]に移動します。逆コンパイルをクリックします。

   public final class DummyClass {
   private int size;

   public final int getSize() {
      return this.size;
   }

   public final void setSize(int var1) {
      this.size = var1;
   }

   public final boolean isEmpty() {
      return this.size == 0;
   }

   public final void setEmpty(boolean value) {
      this.size *= 2;
   }
}

明らかに、Javaクラスにはのgetter関数とsetter関数しかisEmptyなく、フィールドが宣言されていないことがわかります。同様に、KotlinではisEmpty、プロパティはそのフィールドにまったく依存しないため、プロパティのバッキングフィールドはありません。したがって、バッキングフィールドはありません。

次に、isEmptyプロパティのカスタムゲッターとセッターを削除しましょう。

class DummyClass {
    var size = 0;
    var isEmpty = false
}

そして、上記のクラスに相当するJavaは

public final class DummyClass {
   private int size;
   private boolean isEmpty;

   public final int getSize() {
      return this.size;
   }

   public final void setSize(int var1) {
      this.size = var1;
   }

   public final boolean isEmpty() {
      return this.isEmpty;
   }

   public final void setEmpty(boolean var1) {
      this.isEmpty = var1;
   }
}

ここでは、フィールドsizeとisEmpty。の両方が表示されます。プロパティのisEmptyゲッターとセッターはisEmptyそれに依存しているため、はバッキングフィールドです。

バッキングフィールドは、検証を実行したり、状態の変化時にイベントをトリガーしたりするのに適しています。Javaセッター/ゲッターにコードを追加したときのことを考えてみてください。バッキングフィールドは、同様のシナリオで役立ちます。セッター/ゲッターを制御または可視化する必要がある場合は、バッキングフィールドを使用します。

フィールドにフィールド名自体を割り当てるときは、実際にはセッターを呼び出しています（つまりset(value)）。あなたが持っている例では、this.counter = valueスタックがオーバーフローするまで、set（value）に再帰します。を使用するとfield、セッター（またはゲッター）コードがバイパスされます。

私の理解では、使用しているフィールドでのプロパティの値を基準として識別子を取得または設定しますが、変更したりして、プロパティの値を使用する場合、GETまたはセット。

例えば：

class A{
    var a:Int=1
        get(){return field * 2}    // Similiar to Java: public int geta(){return this.a * 2}
        set(value) {field = value + 1}
}

次に：

var t = A()
println(t.a)    // OUTPUT: 2, equal to Java code: println(t.a * 2)
t.a = 2         // The real action is similar to Java code: t.a = t.a +1
println(t.a)    // OUTPUT: 6, equal to Java code: println(t.a * 2)

用語backing fieldは謎に満ちています。使用されるキーワードはfieldです。get/set方法は、すぐに次のれようとしているメンバ変数に次の取得やセットこのドアの保護方法機構を介して。fieldキーワードは、ちょうどされるメンバ変数を参照する設定または取得します。現在、Kotlinでは、getまたはset保護ドアメソッド内で直接メンバー変数を参照することはできません。これは、getまたはsetを再起動するため、残念ながら無限再帰が発生するためです。セットので、深い奈落の底にランタイムダウンをLEDが。

C＃しかし、あなたは直接getter / setterメソッドの内部でメンバ変数を参照することができます。この比較を引用して、このfieldキーワードが現在のKotlinの実装方法であるという考えを示していますが、今後のバージョンで削除され、無限再帰を発生させることなくメンバー変数を直接参照できるようになることを願っています。