Javascript – Speicherfunktion im Objekt – schlechte Praxis? [closed]

Wird es als schlechte Programmierpraxis angesehen, Funktionen in einem Objekt zu speichern, anstatt sie nur (und damit global) zu definieren?

In Betracht ziehen:

1.

Foo = {
    bar: function() {
        alert("baz");
    }   
}

Foo.bar();

vs.

2.

function bar() {
    alert("baz");
}

bar();

Sicher, es könnte etwas weniger Code für das zweite Beispiel sein, aber wenn Sie anfangen, viele Funktionen zu bekommen, wird es chaotisch. Ich finde es zum Beispiel viel, viel sauberer zu verwenden Game.update() statt updateGame(); oder ähnliches. Wenn man tiefer kommt, wie Game.notify.admin(id) und so weiter, es gibt Ihnen noch schöneren Code.

Gibt es Nachteile durch das Speichern einer Funktion in einem Objekt?

Der erste Ansatz wird bevorzugt. Auf diese Weise definieren Sie explizit den Umfang Ihrer Funktionen, anstatt den globalen Umfang zu verschmutzen. Es gibt keine Nachteile bei der Verwendung des ersten Ansatzes. Nur Vorteile 🙂

Fazit: Verwenden Sie immer den ersten Ansatz, um Funktionen zu definieren. Das zweite ist wie Javascript in den 90er Jahren, lassen wir es in Ruhe in der Vergangenheit ruhen und verwenden Sie das richtige Scoping.

In diesem speziellen Fall gehen Sie mit dem ersten. Aber wenn Ihr Foo-Objekt wirklich komplex wird, möchten Sie vielleicht einen anderen Ansatz verwenden, der Ihnen die Möglichkeit gibt, einen Konstruktor zu verwenden. Und auch der erste Ansatz ist manchmal nicht der beste, wenn es um den Funktionsumfang geht:

function Foo(appName){
    this.name = appName;      
}

Foo.prototype.Bar = function(){
   alert(this.name)
}

var a = new Foo("baz");
a.Bar();

Namespace-Objekte sind keine Zauberei, und Sie werden auch keine Probleme haben, wenn Sie viele globale Variablen verwenden. Der Hauptgrund für die Verwendung von “Namespace”-Objekten besteht darin, das Potenzial für doppelte globale Variablennamen zu reduzieren. Ein zweiter Grund besteht darin, ähnliche Funktionen der Einfachheit halber zu gruppieren, z. B.:

// Object example (suggested best practice):
// DOM functions are under myLib.dom
myLib.dom.someDOMFunction0;
myLib.dom.someDOMFunction1;

// Utility functions are under myLib.util
myLib.util.someUtilityFunction0;
myLib.util.someUtilityFunction1;

Beachten Sie, dass das Obige praktisch die gleiche Wahrscheinlichkeit von Duplikaten hat wie ähnlich globale Variablen:

// Global variable example:
myLib_dom_someDOMFunction0;
myLib_dom_someDOMFunction1;

myLib_util_someUtilityFunction0;
myLib_util_someUtilityFunction1;

Natürlich wird Ersteres im Allgemeinen bevorzugt, da es als einfacher zu handhaben angesehen wird. Ich plädiere nicht dafür, dass Sie den zweiten Ansatz übernehmen (ich verwende den ersten), sondern weise nur darauf hin, dass es zwar ein Problem mit der Erstellung vieler globaler Variablen gibt, die sogenannte “globale Namespace-Verschmutzung” jedoch als Gefahr stark überschätzt wird.