nicht angemeldet
Weil du ja die Objektorientierung ins Spiel gebracht hat, könnte man jetzt einwenden, daß in diesem Fall eigentlich nur bgColorChange-Methode nach aussen sichtbar sein sollte, da alles andere eigentlich interne States sind.
Am Ende kann man dann auf ein eigenes Objekt verzichten. ;-)
Man kann viel, einen wirklichen Grund dafür gibt es nicht. Diesen Code finde ich ziemlich unlesbar und unverständlich. Eine klassische OOP-Lösung, die mit tatsächlichen Objekten arbeitet, würde ich hier vorziehen.
function createColorHandler(elem, prop, red, redRange, green, greenRange, blue, blueRange) {
createColorHandler ist ein ziemlich unpassender Name. Zurückgegeben wird ja eine Step-Funktion für eine Farb-Animation. Wieso nicht gleich die Animation als ganze wegkapseln?
function createColorObj(v, r) {
var value = v;
var max = v;
var range = r;
var dir = 1;
return function() {
if (value <= max - range || value >= max) {
dir *= -1;
}
value += dir;
return value;
};
}
Hier wird kein Objekt erzeugt, sondern eine Closure. Kein Problem an sich, aber createColorObj ist kein passender Name, eher createNextColorFunc oder so.
Allgemein: Kapselung in der Programmierung ist [link:http://molily.de/js/organisation-instanzen.html#kapselung@title=kein Selbstzweck] und hat auch nichts mit von außen effektiv nicht sichtbaren Interna zu tun. Kapselung soll einem ermöglichen, Programme zu strukturieren und sinnvolle Schnittstellen anzubieten, um die Schnittstelle von der Implementierung zu trennen. Konkret, nur weil man Closures hat, muss man nicht sämtlichen State in Closures kapseln.
var red = createColorObj(red, redRange);
Eine Funktion namens »red«? Sollte zumindest [pref:t=209455;m=1425820@title=nextRead] heißen.
window.setInterval(createColorHandler(myBody.style, "backgroundColor", 255, 55, 168, 10, 136, 16), 120);
};
Animationen kann man sehr schön objektorientiert lösen und abstrahieren. Dafür gibt es viele gute Beispiele. Dies hingegen ist m.E. keine schöne und lesbare API, ich würde sie nicht benutzen wollen.
Vielleicht sollte jobo erst einmal versuchen, einfachen, klassischen OO-Code zu schreiben, verständliche APIs zu entwerfen und dann stärker funktional zu programmieren. Denn diesen Code finde ich alles andere als elegant.
Mathias