OO bgColorChanger - next try: alles in einem Objekt - kl. opt.

[jobo]

Hallo,

Nehmen wir doch mal dieses Beispiel
init ist klar, die benötigt man in der einen oder anderen Art.
bgColorChange auch
createColorObj erzeugt Objekte die nur intern gebraucht werden. Wozu soll diese von außen zugreifbar sein?
getValue, da ist es sogar gefährlich diese nach außen zu legen, da diese den Wert für den aktuellen Schritt berechnet und jeder weitere Zugriff hier den Ablauf durcheinander bringen würde.
red, green, blue und bgElem sind eindeutig interne Daten und gehen keinen etwas an

Mich überzeugt das. Würde mich mal interessieren, wie Crockford das im Detail sieht. Ob Object-Notation mit teilweise öffentlichen (aber eigentlich privat sein sollenden) Variablen der Übersichtlichkeit halber einer Closure-Konstruktion vorzuziehen sind. Der einzige Grund kann ja die Übersichtlichkeit und somit Wartbarkeit sein. Vielleicht verstehe ich das Wort API ja auch falsch, aber die API, also die Schnittstelle, über die ich das Programm kunfiguriere und starte hat ja mit dem dahinter liegenden Code nix zu tun, oder?

Was nun wieder "eleganter" Code sein soll, erschließt sich mir immer noch nicht. Dazu wünschte ich mir ja ein Beispiel

1. hölzern, übersichtlich, praktikabel aber unelegant (und dennoch performant)
2. wie 1 nur eben "elegant"

Dachte, das könnte am Ende dieses Threads stehen. Vorher-Nachher-mäßig.

Gruß

jobo