Nach dieser Argumentation muss man this immer vermeiden, weil call und apply ein "fremdes" this injizieren können. Was OOP in Javascript ziemlich umständlich macht.
Ein fremdes this injiziert man mMn nur in Funktionen, die darauf ausgelegt sind, per this einen Kontext vorgegeben zu bekommen (Eventhandler in jQuery zum Beispiel). Objektmethoden sind darauf typischerweise nicht ausgelegt. Wenn man es doch tut, ist es halt GIGO[1].
Es bleibt trotzdem schlechter Stil, wenn die Methoden eines Objekts wissen, in welcher Variablen das Objekt gespeichert ist. Eine Lösung ohne this, die etwas taugt, müsste das Module-Pattern verwenden:
var opMap = (function() {
var ops = {
add(a,b) { return { symbol:"+", erwartet:a*b}; },
sub(a,b) { return {...}; },
mul(a,b) { { return {...}; },
div(a,b) { { return {...}; }
};
return {
add(a,b) { return ops.add(a,b); },
sub(a,b) { return ops.sub(a,b); },
mul(a,b) { return ops.mul(a,b); },
div(a,b) { return ops.div(a,b); },
any(a,b) { /* einen Key aus ops.keys() auswählen und ops[key](a,b) aufrufen */ }
};
})();
Das ist dann so etwas wie Selbstverteidigung gegen bösartige this-Injizierer. Aber wenn ich Krieg der Kerne spielen will, besorge ich mir doch lieber eine MARS Umgebung. Aus jeder Klasse ein Modul zu machen kann arg in Boilerplate-Arbeit ausarten.
Rolf
Garbage In - Garbage Out ↩︎