static oder instanz bei einmaliger anwendung?

[MB]

moin community,

eine Klasse die für eine Applikation statische Methoden bereitstellt ist doch performanter im Gegensatz zu einer erzeugten Objektinstanz einer Klasse von der das erzeugte Objekt die Applikation nur einmal benötigt. In dem Fall wäre es doch sinnvoll, die SPA für jede Seite zu der ein User routet eine statischen Controller, View und Model nach MVC-Paradigma anzulegen. Oder nicht?

Ein Beispiel:

• Statische Klassen: Eine Seiten einer SPA
• Objektinstanz: Gästebucheinträge, Dialog Entitäten.

vlg MB

[dedlfix]

Tach!

eine Klasse die für eine Applikation statische Methoden bereitstellt ist doch performanter im Gegensatz zu einer erzeugten Objektinstanz einer Klasse von der das erzeugte Objekt die Applikation nur einmal benötigt.

Vermutlich. Aber spielt das denn eine Rolle? Ist die Anwendung beim Erzeugen einer statischen Seite zu langsam, so dass man über eine Sonderbehandlung nachdenken muss?

• Statische Klassen: Eine Seiten einer SPA

belegen auch dann Speicher, wenn sie keiner anschaut. Brauchen diese Seiten denn jeweils einen eigenen Controller? Reicht da nicht einer für alle, der die unterschiedlichen Inhalte übergeben bekommt?

dedlfix.

[Rolf b]

Sprichst Du rein akademisch, oder hast Du eine bestimmte Programmiersprache im Sinn? Deinen Beispielen zu Folge denkst Du wohl konkret an Javascript.

"Eine Klasse mit statischen Methoden", das gibt's in Javascript nicht, weil es keine Klassen gibt. Man kann welche simulieren (über Konstruktorfunktionen und Prototyp-Objekte). In TypeScript gibt's das zur Laufzeit genausowenig, weil TypeScript bekanntlich in JavaScript übersetzt wird.

Was Dir vorschwebt, ist vermutlich etwas in dieser Art:

var MyStaticClass = {
   foo: function(bla) { return bla+1; },
   bar: function(bla) { return bla-1; }
};

let sieben = MyStaticClass.foo(5);

Es ist aber ein Objekt mit direkt an das Objekt gebundenen Methoden.

Und unter der einzigen Instanz einer Klasse verstehst Du dann vermutlich das hier:

function MySingleton() {
   this.foo = function(x) { return x+1; }
}
MySingleton.prototype.bar = function(x) { return x-1; }

var singleton = new MySingleton();

var fuenf = singleton.foo(3);
var sieben = singleton.bar(9);

In dieser Konstruktion ist der Aufruf von singleton.foo genauso schnell wie der von MyStaticClass.foo, weil es beide Male ein Property direkt am Objekt ist, das die Methodenimplementierung liefert. singleton.bar ist etwas langsamer, weil JavaScript zuerst eine vergebliche Suche am singleton-Objekt durchführt bevor es im Prototypobjekt sucht. Diese Differenz ist aber normalerweise so minimal, dass Du sie vernachlässigen kannst.

Performance ist nicht das Thema.

Etwas anderes ist es, wenn man best-practices der Objektorientierten Programmierung betrachtet. Man versucht nämlich, Abhängigkeiten zwischen Klassen zu minimieren. Wenn Du eine Klasse B hast, die statische Methoden der Klasse A nutzt, dann hast Du eine harte Abhängigkeit zwischen B und A. Angenommen, die Methoden von A sind keine isolierten Logiker, sondern greifen auf Ressourcen zu oder turnen im DOM herum. Dann bist Du nicht mehr im Stande, die Klasse B einem Unittest zu unterziehen, ohne das Laufzeitumfeld komplett bereitzustellen. Wenn B aber nur eine Abhängigkeit zu einem Interface I hat, das von A implementiert wird, kannst Du für den Unittest dem getesteten Objekt der Klasse B eine Klasse XY unterschieben, die ebenfalls I implementiert, aber die Aktivitäten von A nur simuliert.

Um das zu systematisieren, verwendet man Tools zur Dependency Injection.

TypeScript setzt dem Ganzen dann wiedermal die Krone auf. Da kannst Du eine Funktion definieren, die ein bestimmtes Interface erwartet, und schmeißt dann beim Aufruf eine Klasse ein, deren statische Methoden das Interface implementieren. Das klappt deshalb, weil JavaScript keine Klassen kennt, sondern Prototypobjekte. D.h. für Unittests kannst Du dann eine Mock-Klasse einschmeißen.

Ich hoffe, deine Verwirrung nicht allzusehr gesteigert zu haben...

Rolf

[MB]

nabend Rolf,

Und unter der einzigen Instanz einer Klasse verstehst Du dann vermutlich das hier:

ne sorry. ich meinte mit Objektinstanz new Foo( 'bar' ); und mit staischer Klasse Foo.bar(). Ich wollte damit die selbe Funktion zweier verchiedener Klassenarten zum ausdruck bringen.

also ist es hupe ob ich nun ne Klasse ein einziges mal instanziiere oder eine statische Klasse verwende mit der selben funktionalität? Ich mein eine Klassen muss ja erst einmal aus der Schablone der Klasse erzeugt werden. Klingt für mich nach mehr Aufwand als wenn eine statische klasse verwende die schon bereigestellt ist.

Ich hoffe, deine Verwirrung nicht allzusehr gesteigert zu haben...

ich komm klar danke keine sorge ;). Will heißen das ich noch viel lernen muss.

vlg MB

[dedlfix]

Tach!

Ich mein eine Klassen muss ja erst einmal aus der Schablone der Klasse erzeugt werden. Klingt für mich nach mehr Aufwand als wenn eine statische klasse verwende die schon bereigestellt ist.

Mach dir um diesen Aufwand keine allzugroßen Gedanken. Das geht üblicherweise im Grundrauschen unter. Du wirst ja keine Millionen von Instantiierungen in kurzer Zeit durchführen wollen. Es kommt beim Programmieren weniger darauf an effizientestmöglichen Code zu erstellen, sondern mehr dass der Wartungsaufwand gering bleibt. Dazu gehört, dass man vorwiegend für Menschen verständlichen Code schreibt und Ungewöhnlichkeiten möglichst vermeidet.

dedlfix.

[Rolf b]

Und unter der einzigen Instanz einer Klasse verstehst Du dann vermutlich das hier: ne sorry. ich meinte mit Objektinstanz new Foo( 'bar' ); und mit staischer Klasse Foo.bar().

Schreibte ich das nicht? Außer dass ich nicht 'bar' an den Konstruktor übergeben habe...

Ich mein eine Klassen muss ja erst einmal aus der Schablone der Klasse erzeugt werden.

Eine "Schablone der Klasse" gibt es nicht unbedingt. In einer statischen Programmiersprache macht das Meiste der Compiler für Dich, da ist ein new nicht mehr als eine Speicherallocation auf Stack oder Heap (was nur messbare Zeit kostet wenn der Müllsammler loslaufen muss) und das Kopieren von ein paar Bytes an Daten, die auf die VFT verweisen (Siehe "Vererbung" vom 31.01.17). In JavaScript kommt's drauf an, da baust Du entweder ein Prototypobjekt, und zwar genau einmal, und das ist genauso schnell wie das Erzeugen einer "statischen Klasse". Beim new MyClass() wird dein Prototyp zum Prototyp des neuen Objekts. Dafür wird genau eine Objektreferenz kopiert. Oder Du erzeugst die Instanzmethoden dynamisch im Konstruktor, und DANN wird's langsamer, weil dann für jede Methode ein Funktionsobjekt erzeugt wird. Im Falle eines Singleton-Objekts ist das aber auch wieder egal.

Klingt für mich nach mehr Aufwand als wenn eine statische klasse verwende die schon bereigestellt ist.

Ja schon. Aber es ist vor allem Schreibaufwand. Der Runtime-Aufwand wird kaum messbar sein. Wenn Du hier eine Entscheidung basierend auf Laufzeitkosten treffen willst, befinden wir uns im Bereich der Mikrooptimierung.

Wie schon mal gesagt, das entscheidende Kriterium für statische Klasse vs Singleton-Objekt ist, dass das Singleton-Pattern für JavaScript wenig relevant ist, weil die Sprache andere Möglichkeiten bereitstellt. Aus DIESEM Grund ist die statische Klasse das Richtige.

Rolf

[pl]

moin community,

eine Klasse die für eine Applikation statische Methoden bereitstellt ist doch performanter im Gegensatz zu einer erzeugten Objektinstanz einer Klasse von der das erzeugte Objekt die Applikation nur einmal benötigt. In dem Fall wäre es doch sinnvoll, die SPA für jede Seite

SPA für jede Seite? Was verstehst Du denn unter eine SPA?

zu der ein User routet eine statischen Controller, View und Model nach MVC-Paradigma anzulegen. Oder nicht?

Wenn es nur eine Seite gibt, brauchts auch nur eine Route. Diese Bedingung erfüllt eine SPA hinreichend ;)

MfG