Sind "Getter" und "Setter" in JavaScript notwendig?

Question

class Employee { 

    constructor(name, age) { 
     this._name = name; 
     this.age = age; 
    } 

    doWork() { 
     return `${this._name} is working`; 
    } 

    get name() { 
     return this._name.toUpperCase(); 
    } 

    set name(newName){ 
     if(newName){ 
      this._name = newName; 
     } 
    } 
} 

let man = new Employee('A', 10); 
console.log(man.name, man.age); 
man.name = 'B'; 
man.age = 20; 
console.log(man.name, man.age); 

Hier ist mein Code. Ich habe ein und setter für _name Mitglied erstellt. Ich habe kein getter und kein setter für age erstellt.

Aber beide können aktualisieren Sie diese beiden Felder wie diese

Also ich bin verwirrt, sind getter und setter notwendig in JavaScript?

Answer 1

Ja, ein Getter oder Setter kann manchmal sehr nützlich sein, aber sie müssen nur verwendet werden, wenn ihre spezifische Funktionalität benötigt wird - ansonsten kann ein einfacher Zugriff auf Eigenschaften ohne einen Getter oder Setter in Ordnung sein.

Ein Getter wird verwendet, wenn Sie bei jeder Anforderung einer Eigenschaft einen Code ausführen möchten. In Ihrem Beispiel gibt der Getter immer eine Großbuchstabenversion des Namens zurück, unabhängig davon, wie der Groß-/Kleinschreibung des Namens entspricht, während der tatsächliche Fall für die interne Verwendung reserviert wird.

Ein Setter wird verwendet, wenn Sie jedes Mal Code ausführen möchten, wenn eine Eigenschaft festgelegt wird. In Ihrem Fall verhindert es das Setzen eines falschen Namens. Sie können keine dieser Funktionen ohne Getter/Setter implementieren.

Direkter Zugriff auf Eigenschaften ist eine sehr gute Möglichkeit, Dinge zu tun, wenn Sie keine spezielle Logik benötigen.

Answer 2

Der Grund, warum wir die Klasse verwenden, besteht darin, dass alle Eigenschaften eines Elements eine Einheit sind. Sie können jedoch nur durch Erstellen eines Objekts erreicht werden und können Eigenschaften an diese anhängen, wann immer Sie benötigen.

Wenn der Code größer wird, können Sie nicht in der Lage zu debuggen, wo Ihr Code fehlschlägt.Wenn Sie die Struktur folgen, können Sie leicht Dubug. Weil jede Entität wird in separaten Datei und Logik wird separat sein.

Aber JavaScript ist eine objektorientierte Programmiersprache. Der Grund, warum wir Klassen anstelle von Objekten verwenden, ist das gleiche für Getter und Setter. Es ist nicht wie wo Sie wo Sie nicht brauchen können. Es ist eine gute Praxis um alle Eigenschaften über Setter und Getter einzustellen und zu erhalten.

Nach einiger Zeit können Sie einige Bedingungen hinzufügen, wenn Sie eine Eigenschaft festlegen. Wenn das Alter einer Person größer als 100 ist, sollten Sie diese Eigenschaft nicht festlegen. Zu diesem Zeitpunkt müssen Sie Ihre Basisklasse ändern Und das wird der schwierigste Teil unseres Lebens (Code Refactoring). Um diese Art von Problemen zu vermeiden und Ihre Variablen sicher zu machen, sollten wir aus meiner Sicht Getter und Setter verwenden Antwort

Answer 3

mit getter und setter Methoden auf Ihrer Eigenschaft in der Klasse ab, wenn Sie eine Eigenschaft machen wollen nur schreibgeschützt werden, um seine wahre getter Methode wie folgt zu verwenden:

function Person(name, age){ 
 
    var _name = name; 
 
    this.age = age; 
 
    
 
    this.getName = function(){ 
 
    return _name; 
 
    } 
 
} 
 

 
var teacher = new Person('Sara', 24); 
 

 
//now you can just get the name of teacher 
 
alert(teacher.getName()); 
 

Answer 4

notwendig?

Gibt es Szenarien, die am besten als Getter/Setter ausgedrückt werden? Ja.Betrachten Sie „Computed Eigenschaften“:

//declare an object 
rectangle = { 
    x: 10, 
    y: 20, 
    get area() { return this.x * this.y } //won't occupy storage 
} 

//usage 
log('the area is', rectangle.area)  //=> 'the area is 200'. 
              // cleaner syntax (no parentheses) 

Betrachten wir die Bedürfnisse der API-Designer - höchstwahrscheinlich sie werden über hyper-sensibel sein, wie Benutzer sehen ihre API. Jedes Bit (oder in diesem Fall Klammern) zählt zum Bereinigen der Schnittstelle.