[SOLVED] Auf Änderung eines Klassen Attributs reagieren?

[OliverIO]

@iphilbln

da stimmen ein paar sachen nicht in deinem code.
ich gehe davon aus, das du das Event-System von node meinst?
Schau dir mal das Beispiel hier an
https://www.w3schools.com/nodejs/nodejs_events.asp
das ist ein wenig verständlicher wie das in der node doku selbst.

Im Prinzip fügst du deiner Klasse ein eventEmitter-Objekt hinzu.
Mit dem kannst du bei Änderung eines Attributs ein Event mit dem emit-Befehl erzeugen.

Jemand der deine Klasse verwendet, der kann dann bspw mit dem Befehl xxx.on("eventname",Funktionsbaustein) darauf reagieren.

und hier 2 Beispielcodes wie man das in eine Klasse einbaut.
Einmal über Vererbung und einmal über Komposition.
https://stackoverflow.com/questions/59100598/how-do-i-add-custom-events-to-classes-in-node

Nachtrag: Falls du iobroker hier nur zum lernen verwendest, dann lad dir lieber visual code runter.
der bietet die viel mehr support, was das debuggen angeht und ist kostenlos
https://code.visualstudio.com/

[Codierknecht]

@iphilbln sagte in Auf Änderung eines Klassen Attributs reagieren?:

@codierknecht hmm ne das hab ich nicht vor. Dann wäre klar, dass ich die Methode komplett neu definieren müsste.
In meinem Skript gibt es eigentlich eine Methode die für alle Klassen gleich ein Attribut setzt. Wenn sich dieses Attribut ändert, soll in der erbenden Klasse eine Methode aufgerufen werden, die sich dann aber unterscheidet. Hoffe das war verständlich?

Eine Basisklasse sollte von ihren Nachfahren völlig unabhängig sein.
Besondere Verhaltensweisen werden ausschließlich in den abgeleiteten Klassen definiert.
Also wird - zumindest in "meiner" Sprache - in den abgeleiteten Klassen der Setter für die Attribute (Member) überschrieben.
Der Setter wird in der Basisklasse als "abstract" definiert - damit muss er in den Nachfahren implementiert werden.
Und so kann das halt in jeder Klasse anders geregelt werden.

[iPhilBln]

@oliverio Danke, das war genau das was ich gesucht habe.
Hab mir jetzt mal fix mein Beispiel umgeschrieben:

'use strict';

const events = require('events');


class Name{
    constructor(name){
        this.name = name;
        
        this.listener = new events.EventEmitter();
    }

    setName(name){
        this.name = name;
        this.listener.emit('name', this.name);
    }
}

class Surname extends Name{
    constructor(name){

        super(name);
        this.surname = undefined;

        this.listener.on('name', this.setSurname );
    }

    setSurname(surname) {
        surname === 'Max' ? this.surname = 'Mustermann' : this.surname = undefined;

        console.log(`Vorname: ${this.name} Nachname: ${this.surname}`);
    }
}

const person = new Surname('Max');

person.setName('Paul');

setTimeout(() => {
    person.setName('Max');
}, 2 * 1000);

Läuft soweit erstmal, sehe aber grade noch deinen Nachtrag mit den Beispielen auf Stackoverflow. Werde ich mir später mal in Ruhe anschauen.

Und ich schreibe meine Skripte mit VS Code. Javascript ist aber noch recht neu für mich, beginne nur so langsam meine Blockly Skripte zu optimieren und direkt mit JS zu schreiben.

[iPhilBln]

@codierknecht du spielst eher auf Java an oder? So wie ich das verstanden habe, funktioniert das bei Javascript mit Klassen im Großen und Ganzen anders als bei Java. Das Attribut der übergeordneten Klasse soll durch die erbende Klasse auch in keinster Weise beinflusst werden oder ähnliches, es soll nur auf die Änderung reagiert werden.
Das was @OliverIO geschrieben hat, ist schon das was ich suche.

[OliverIO]

@iphilbln
ne da hat @Codierknecht schon recht.
Die Regeln der Objektorientierung gelten für alle Programmiersprachen.
Aber in der praktischen Umsetzung muss das jeder selber lernen und durch Fehler auch erfahren wo das Problem liegt.
Deine beiden Klassen machen für mich auch nicht soviel Sinn, bzw würde ich auf so einem Detaillevel keine separaten Klassen machen, da die wiederverwendung hier nicht so groß´ist (also name könntest dann bei surename prename midname evtl noch additional names verwenden, wenn du eine klammerklasse evtl namens person oder contact hast.
den zusätzlichen code, den eine separate klasse benötigst, kannst du dir sparen, da du die umsetzung der Unterschiede direkt in einer Klammerklasse umsetzen kannst.
da hast du dann auch mehrere Attribute, mit dem du dann auf eine Änderung mit einem Event reagieren kannst.

darüber hinaus doppelst du in deinem beispiel die daten.
Am Ende ist der surname einmal in der variable surename und auch in name der basisklasse gespeichert

[iPhilBln]

Ja das Beispiel soll eigentlich auch nur verdeutlichen wo es grade hapert, bei so wenig Attributen würde ich jetzt prinzipiell auch keine zwei Klassen erstellen. Im eigentlichen Skript existieren aber wesentlich mehr Methoden und Attribute. Daher war eigentlich die Idee eine Oberklasse zu schreiben und nur Methoden die nicht identisch sind dann in einer erbende Klasse zu definieren.
@OliverIO Mir kommen aber bei deiner Antwort zwei Fragen auf.

• 1. Was sind Klammerklassen?
• 2. Wieso doppel ich meine Daten in dem Beispiel? Es existiert doch nur eine Instanz "Surname" in dem Beispiel.

[OliverIO]

@iphilbln

klammerklassen ist meine umschreibung dafür das wenn du das so fortführen würdest, dann hättest du ganz viele unterklassen für eine person.. wie geschrieben das macht in diesem beispiel nicht so viel sinn.
2)
name hat das attribut name (Zeile
surname hat das attribut surname Zeile 23 und 29 (wobei 29 sogar nur eine blockvariable ist, die nach Aufruf von setSurname wieder vergessen wird.
Wenn du die Klasse surename erzeugst (Zeile 35) dann wird natürlich auch die basisklassen mit erzeugt.(surename extends name zeile 19)
der eine name wird durch den constructor belegt der andere durch eine methode. wie gesagt von der struktur ist das nicht alles so logisch. ich würde einfach das folgende machen

/*jshint esversion: 8 */
const events = require("events");
class Person{
    constructor(name,surname){

        this.event = new events.EventEmitter();
        this._name = name;
        this._surename = surname;
    }
    set name(name) {
        this._name=name;
        this.event.emit("attributChanged","name",name);
        this.event.emit("attributChangedName",name);
     }
    set surname(surname) {
        this._surname=surname;
        this.event.emit("attributChanged","surname",surname);
        this.event.emit("attributChangedSurname",surname);
    }
    get name() {
        return this._name;
    }
    get surname() {
        return this._surname;
    }
}

var p = new Person("aaa","bbb");
p.event.on("attributChanged",(property,value)=>{
    console.log(`${property} ${value}`);
});

p.name="ccc";

[Codierknecht]

@iphilbln sagte in Auf Änderung eines Klassen Attributs reagieren?:

du spielst eher auf Java an oder?

Java ist die dunkle Seite der Macht!
Nein, ich verwende in der Hauptsache Delphi. Wie @OliverIO schon schrieb: Die Regeln der Objektorientierung gelten prinzipiell für beliebige Sprachen.

Daher war eigentlich die Idee eine Oberklasse zu schreiben und nur Methoden die nicht identisch sind dann in einer erbende Klasse zu definieren.

Genau so ist es gedacht.

[iPhilBln]

@oliverio hmm ich weiß nicht, ob wir eventuell grade etwas aneinander vorbeireden, weil du dich sehr an meinem simplen Beispiel von oben aufhängst. Mir ging es dabei primär darum mit einem abstrakten Beispiel die generelle Funktion zu verstehen . Ich denke wir sind uns einig, dass man bei nur 2 Attributen nicht mit 2 Klassen und Vererbung arbeitet. Vielleicht kam das vorher nicht so gut rüber?
Mein eigentliches Skript wird meine Heizungssteuerung. Der prinzipielle Aufbau sieht dann folgende Klassen vor:

• class Heating
• • alle wichtigen, grundlegenden Steuerungen und States
• class "Raumname" extends Heating
• • Sonderfunktionen des jeweiligen Raums ( Nachtmodus, Aufstehen, Batteriewarnungstext, etc)

Daher muss die erbende Klasse ja auf Änderungen einiger Attribute der Klasse Heating reagieren, sofern ich nicht jede Methode in der erbenden Klasse neu schreiben möchte. Nichts desto trotz hast du mir den richtigen Anstoß mit dem Eventemitter geliefert, der mir das ermöglicht.

@Codierknecht

Daher war eigentlich die Idee eine Oberklasse zu schreiben und nur Methoden die nicht identisch sind dann in einer erbende Klasse zu definieren.

Genau so ist es gedacht.

Gut, dann sind wir denke ich einer Meinung.

[OliverIO]

@iphilbln

dann ist gut