Domino 9 und frühere Versionen > ND8: Entwicklung - XPages

[Erledigt] Javascript Klasse

<< < (3/3)

koehlerbv:
Michael, auch wenn wir jetzt völlig off-topic sind (und jeder bisher irgendwie Recht hatte  ;)):
Porsche ist Murks in dem Sinne: Wenn man schon extravagant sein will (sooo besonders schnell ja nicht unbedingt!) und zuviel Schotter hat, dann Mi-24. Die ist schneller, bietet viel mehr Platz, hat den tolleren Klang und ihr ist nichts im Weg. Zudem noch bis zu acht Plattformen für "Wir machen den Weg frei!" - falls es mal hart auf hart kommt. Und für andere Hindernisse wie Berge und Hochspannungsmasten gibt es jeweils natürlich auch 'ne App  ;D Die Reichweite ist auch besser. Viel besser. Der Sprit ist natürlich eher besonders und fliesst reichlich, ist aber im Literpreis billiger. Alles hat seine Vor- und Nachteile.

Was Picasso und da Vinci angeht: Hätte Picasso die Nasen an die richtige Stelle gepappt, wären daraus noch immer keine "schönen Menschen" geworden. "Guernica" ist für mich trotzdem ein beeindruckendes Bild.
Die "Mona Lisa" ... Okay, wenn zwangsweise auf einer Insel ausgesetzt und eine Frau dabei, dann eher diese als Picasso-Figuren - da muss man wenigstens nicht gleich vor Entsetzen ins Meer springen  ;D

Back to topic: Es gibt oft mehrere Wege, Code stabil, wartbar, wiederverwendbar zu machen. Hauptsache, man treibt nicht jeden Tag eine neue Sau durchs Dorf ... und bleibt niemals stehen, wo man ist. Eine "neue Sau" kann natürlich auch sehr hilfreich sein.

Bernhard

flaite:
Ok. Ich hab Marco nicht aufmerksam gelesen. Bin nämlich mit Dir glaub ich völligst einer Meinung.
In die gleiche Richtung geht auch meine zunehmende Ablehnung von dojo, mit dem ich gearbeitet habe, insbesondere im Vergleich zu jQuery, das ich für wesentlich effektiver halte.
In dojo wird krampfhaft versucht, ein Klassen-Schema in eine Sprache zu bringen, die das einfach überhaupt nicht benötigt.

Gandhi:
Und wo wir hier schon bei Buchempfehlungen sind: Neben Crockford - dessen Buch wirklich das wohl beste JS Buch auf dem Markt ist, kann ich Stoyan Stefanov sehr empfehlen, insbesondere das Buch über Design Patterns in JavaScript.

Back to topic:
Was ich damit sagen will: Aus meiner Sicht ist die Klassenorientierte Objektorientierung nicht in irgendeiner Weise effizienter als andere Paradigmen.

Die beiden vorherrschenden Paradigmen von JavaScript sind die Funktionale Programmierung und die Prototypische Objektorientierung (eigentlich einfach nur Objektorientierung - wenn man im anderen Fall korrekterweise von Klassenorientierung sprechen würde).

Wirklich gut zu nutzen ist JavaScript nur, wenn man sich auf JavaScript einlässt und es nicht versucht umzuinterpretieren.
Genauso mit Java, C++, ...
Sprachen haben Stärken, Sprachen haben Schwächen - Klassenorientierte Objektorientierung und Interfaces sind keine Stärken von JavaScript.
Der Rest schon. Bin noch am Erkunden, was man alleine mit funktionaler Programmierung anfangen kann - das ist ein weites faszinierendes Feld.

JavaScript wird nach meiner Meinung noch eine noch größere Rolle im IT Zirkus bekommen. Nicht nur im Frontend und nicht nur in Domino SSJS, sondern auch im Zusammenhang mit Cloud Computing, V8/Node.js

JQuery oder Dojo? Ich bevorzuge Dojo. Weniger weil ich glaube, dass es besser ist, sondern weil es in sich vollständiger ist. Es gibt zwar gleiche Funktionalitäten auch unter jQuery über Erweiterungen - da ist dann aber nicht mehr alles aus einem Guss.  Wenn ich auf Dojo basierend im Dojo Stil Erweiterungen basteln würde, hätte ich vielleicht die gleichen Probleme - ich nutze es aber weitgehend unverändert, also ohne irgendwelche Erweiterungen aus Dojo zu basteln.
Vielleicht wäre jQuery auch so besser - aber Dojo ist einfach gut genug für mich und meine Zwecke.

flaite:
Naja. Ich hab meinen Senf dazugegeben, weil ich den Eindruck hatte, dass Michael einem oft eingesetzten, aber problematischen Vorgehensmodell folgte.

1.) Sich sagen: Ich weiss, "was Objekt-Orientierung ist" Objekt-Orientierung ist mit Klassen. 
2.) Mit dem "Vor"-Urteil von 1.) code schreiben.
3.) Solange auf den Code einprügeln, bis er das tut, was ich denke OO in der Sprache darstellt.
4.) Einer Reflektion, ob 3) den code verständlicher, erweiterbarer und anpassbarer macht, ausweichen. 

OO ist aber wie praktisch jeder abstrakter Begriff ein oft sehr dehnbares Konstrukt. Eine abstrakte Hülle. Eine Art Götze, der für etwas steht, das allzuvoft mehr durch Hineinfabulieren des Betrachters bestimmt wird als das Ding für sich.  ;D
Wichtiger und herausfordernder ist aber für mich eigentlich die Frage, wie OO in der konkreten Implementierung der Sprache verstanden und wie ich das nützen kann. Und ich hatte den Eindruck, das Michael vor diesen Fragen ausweicht. Und ich hab einfach vorgeschlagen, das noch einmal zu überdenken. Eigentlich eine Forderung nach mehr Demut in der Annäherung gegenüber dem Inhalt des Begriffes. Deshalb widersprach ich auch dem Arroganz-Vorwurf gegen mich.   

Gruß Axel

Gandhi:
Sehe ich ähnlich

Navigation

[0] Themen-Index

[*] Vorherige Sete