【Kotlin学習日記】Day 10:インタフェース

皆さん、こんにちは、William李梓峰です.私のKotlinの勉強の旅に参加してください.今日は私がKotlinを勉強した10日目で、内容はInterfaces-インタフェースです.
公式ドキュメント:

https://kotlinlang.org/docs/reference/interfaces.html

Interfaces-インタフェース
Interfaces in Kotlin are very similar to Java 8. They can contain declarations of abstract methods, as well as method implementations. What makes them different from abstract classes is that interfaces cannot store state. They can have properties but these need to be abstract or to provide accessor implementations. KotlinのインタフェースはJava 8に似ています.Java 8のインタフェースには抽象的な方法のほかにdefault method(デフォルトの方法では、インタフェースが更新されるとすべての実装クラスに新しい方法を強制的に実現させ、災害の発生を避けるため)を書くことができるからです.インタフェースが抽象クラスと唯一異なる点は,インタフェース自体がステータスを格納できないことであり,インタフェースの属性はabstractであるか,開発者がアクセサ(getter setter)の具体的な実装を提供する必要があることである.
An interface is defined using the keyword interface{:.keyword}interfaceキーワードでインタフェースを定義しましょう.

interface MyInterface {
    fun bar()
    fun foo() {                     //     Java 8     default 。。
      // optional body
    }
}

Implementing Interfaces-実装インタフェース
A class or object can implement one or more interfacesはJavaと同様に、1つのクラスで複数のインタフェースを実現することができます.

class Child : MyInterface {    //                
    override fun bar() {
        // body
    }
}

Properties in Interfaces-インタフェースのプロパティ(ポイント)
You can declare properties in interfaces. A property declared in an interface can either be abstract, or it can provide implementations for accessors. Properties declared in interfaces can't have backing fields, and therefore accessors declared in interfaces can't reference them. インタフェースでプロパティを宣言できます.この宣言のインタフェース内の属性は抽象的であってもよいし、具体的なアクセサ実装を提供してもよい(上述した).ただし、インタフェースのプロパティは、アクセサがあってもスタンバイフィールドを持つことはできません(Day 9ではスタンバイフィールドと言っていますが、fieldはsetter getterにしか書けません.fieldの機能はオブジェクトのthisに相当します).そのアクセサではfieldを呼び出すことはできません.

interface MyInterface {
    val prop: Int // abstract           //      open     

    val propertyWithImplementation: String
        get() = "foo"     //           ，       field

    fun foo() {
        print(prop)
    }
}

class Child : MyInterface {
    override val prop: Int = 29    // override           
}

Resolving overriding conflicts-複写の衝突を解決する
When we declare many types in our supertype list, it may appear that we inherit more than one implementation of the same method. For exampleスーパークラスリストで複数のタイプを宣言すると、同じ名前のメソッドが複数の継承実装される場合があります(コードを直接見てください.この話は少し分かりません).例えば、

interface A {
    fun foo() { print("A") }
    fun bar()
}

interface B {
    fun foo() { print("B") }
    fun bar() { print("bar") }
}

class C : A {
    override fun bar() { print("bar") }
}

class D : A, B {
    override fun foo() {
        super.foo()/   にA  を び す
super.foo()
}
override fun bar() {
super.bar()
}
}

Interfaces A and B both declare functions foo() and bar(). Both of them implement foo(), but only B implements bar() (bar() is not marked abstract in A, because this is the default for interfaces, if the function has no body). Now, if we derive a concrete class C from A, we, obviously, have to override bar() and provide an implementation. インタフェースAおよびインタフェースBは、メソッド「foo()」および「bar()」を宣言する.どちらのインタフェースもメソッド「foo()」を実装していますが、インタフェースBは「bar()」を実装しています(bar()はインタフェースAにabstractと表記されていません.具体的に実装されていないので、デフォルトでは抽象的なメソッドとしてJavaと同じでしょうか).ここで,クラスCにインタフェースAを実装させると,クラスCは「bar()」メソッドを複写し,具体的な実装を提供しなければならないことが明らかになった.
However, if we derive D from A and B, we need to implement all the methods which we have inherited from multiple interfaces, and to specify how exactly D should implement them. This rule applies both to methods for which we've inherited a single implementation (bar()) and multiple implementations (foo()). しかし、クラスDにインタフェースAとインタフェースBを実装させる場合、これらのインタフェースを継承し、クラスDがどのように実装されるかを示すすべての方法を実装する必要があります.これらのルールは、「bar()」でも「foo()」でもすべての方法に適用されます.△ここでは少しくどい話ですが、実際にはクラスDにすべての方法を直接複写させることです.ここの状況は少し複雑で、実際の開発では異なるインタフェースを実現する同じ方法名のシーンはほとんどありません.
完了