Verwendung des Kotlin-Attributpräfixes „_“.

Beim Schreiben von Java verwenden wir normalerweise mPräfixe beim Benennen von Feldern. Warum verwenden wir diese Methode jedoch nicht beim Schreiben von Kotlin? Da Funktionen in Kotlin erstklassige Bürger sind und Eigenschaften und Funktionen der obersten Ebene definieren können, empfiehlt der Beamte eine solche Namenskonvention nicht mehr. Und in den meisten Fällen werden in Kotlin definierte Variablen propertiesin Java als Attribute ( ) statt als Felder ( field) bezeichnet. Kotlin verwendet „_“ als Präfix für Attribute, die als Backup-Attribute bezeichnet werden. Lesen Sie zunächst die offiziellen Dokumente, um mehr zu erfahren.

Hintergrundfelder

Kotlin-Klassen können keine Felder haben. Manchmal benötigen Sie jedoch ein Hintergrundfeld, wenn Sie benutzerdefinierte Accessoren verwenden. Für diese Zwecke stellt Kotlin automatische Backup-Felder bereit, auf die über Feldbezeichner zugegriffen werden kann:

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

Auf diesen fieldBezeichner kann nur innerhalb des Attributs zugegriffen werden set{} get{}. Wenn ein benutzerdefinierter Accessor fieldüber einen Bezeichner darauf verweist, wird ein Hintergrundfeld für die Eigenschaft generiert. In den folgenden Fällen gibt es kein Hintergrundfeld:

val isEmpty: Boolean 
    get() = this.size == 0

Backing-EigenschaftenBacking-Eigenschaften

Kotlin-Fallback-Attribute , das Folgende ist das offizielle Beispiel.

private var _table: Map<String, Int>? = null
val table: Map<String, Int>
    get() {
        if (_table == null) {
            _table = HashMap() // Type parameters are inferred
        }
        return _table ?: throw AssertionError("Set to null by another thread")
    }

Wir sehen diese Art des Schreibens oft in manchen Codes und viele Leute fragen sich, warum das gleiche Attribut von zwei Variablen gehalten werden muss. Im Allgemeinen weisen diese Codes die folgenden Merkmale auf:

• Private Attribute sind 更多bedienbar
• 更少Bedienbarkeit extern verfügbar gemachter Attribute

Beispiel 1:

class TestFragment: Fragment() {

    private var _binding: VB? = null

    protected val binding: VB
        get() = requireNotNull(_binding) { "The property of binding has been destroyed." }

    ...
    override fun onDestroyView() {
        super.onDestroyView()
        _binding = null
    }
}

Beispiel 2:

class EffectViewModel: ViewModel() {
    private val _effect = MutableSharedFlow<Effect>()
    val effect: SharedFlow<Effect> by lazy { _effect.asSharedFlow() }
}

Beispiel 3:

class LiveDataViewModel: ViewModel() {
    private val _liveData = MutableLiveData<Int>()
    val liveData: LiveData<Int> = _liveData
}

Sicherungsattribute können einen besseren sicheren Datenfluss aufbauen, da die Betriebsberechtigungen für die Daten verschärft werden und der Außenwelt nur Leseberechtigungen erteilt werden. Dies gewährleistet die Datensicherheit und erleichtert die Lokalisierung von Problemen und die Nachverfolgung von Daten im UDF-Datenfluss.