Ja - und? Die Farbe gehört ja anscheinend zur Schnittstelle.
Was hat denn eine Eigenschaft mit Implementierungsdetails zu tun?
Warum nicht?
Äh... nein. Dafür gibt es die ES5-Setter und Getter. Die meinte ich mit
.
und was meinst du dann mit
get color ()
{
return mycolor;
}getColor = function()
{
return mycolor;
}Ich meinte eigentlich Object.defineProperty() - aber ist das gleiche Prinzip.
Die defineProperty-Notation ist sogar noch nerviger auf der Implementationsseite, aber
ich meinte die Anwendungsseite. Dort wird das ja auch (normalerweise) öfters verwendet, wobei die Eigenschaft nur einem definiert werden muss.
Finde ich nicht. Bei der ersten Variante ist es eindeutig klar, was gemacht wird. Ich bekomme die Eigenschaft color vom Objekt obj. Bei der zweiten bekomme ich den Rückgabewert der Funktion getColor() von obj. Ich weiß, dass das so üblich ist, damit das gleiche zu meinen, aber ich kann mir viele Szenarien vorstellen, wo .getColor() ein Funktionsname für eine andere Operation ist (z.B. dass obj aus irgendwas anderem die Farbe ausliest und als Rückgabewert einen Boolean über der Erfolg zurückgibt).
den hauptgrund hast du schon genant:
das geht auch in vielen sprachen nur so.
Das ist ja an sich noch kein Grund, das in JS nicht anders zu machen...
Muss man ja auch nicht. Genau das sind doch Implementierungsdetails, die man verbergen sollte...
nein, man darf überhaupt nicht auf membervariablen zugreifen. sieht aber ein setter/getter zugriff aus wie membervariablenzugriff, sollte man ein ungutes gefühl haben als anwender der schnittstelle.
Natürlich hängt dahinter eine Funktion. Aber das ist völlig egal, im JS sieht man davon nichts. Wie gesagt - das sind Implementierungsdetails. Im Grunde genommen ist ja jede Anweisung, die du an die CPU sendest eine Funktion. Trotzdem willst du keinen Maschinencode schreiben...
Ja, ist sie. Aber wenn du schon was refernzierst, solltest du schon das Richtige und Offizielle und nichts Proprietäres nehmen.
Ja und... auch eine öffentliche Eigenschaft ist als Schnittstelle erkennbar. Und welche Eigenschaften öffentlich sind, steht in der Dokumentation oder die nicht öffentlichen sind anderweitig markiert.
Äh - warum? Genau deswegen gibt es in Java public... gibt es jetzt in JS nicht - bzw. es gibt kein private/protected - aber JS ist sowieso extrem flexibel, so dass man jedes Interface kaputt bekommt.
Wofür gibt es Dokumentationen? Wenn da drin steht, dass man das so verwenden kann, dann braucht man kein ungutes Gefühl haben.
Ich lade da die Seite einfach mit aktiviertem HttpFox neu und kann dann den Text aus den mitgeschnittenen POST-Variablen wieder rauskopieren.
das meinte ich mit "normalerweise kann man dann zurück und den text kopieren", aber wie gesagt, vor einiger zeit (kann durchaus schon über ein jahr sein), war der text nach dem login noch da.
naja, eine anweisung ist eine anweisung und keine funktion, eine funktion besteht aus mehreren anweisungen und kann man mit call aufrufen, der vergleich taugt nichts.
du hast input.value als beispiel genommen nicht ich. aber das was ich für value gesagt habe gilt für alle propertys.
in einer schlechten schnittstelle, in einer guten sind nur pure virtuelle methoden, in java abstract
wo nur funktionen reingehören, weil
die doku ist keine schnittstellendefinition, sondern erklärt diese im detail
der ist aber auch nur in js(scriptsprachen) einsehbar, und ändert nichts an der tatsache, dass man es bei der anwendung nicht auseinanderhalten kann.
3-5 mal zürück und antworten geht eigentlich auch, keine ahnung was gestern war
ja, was ich aber schade finde, weil, wie du selbst sagst, in js keine echte interfacedefinition möglich ist, was auch wieder gut ist, weil js sehr flexibel ist.
Und eine Anweisung besteht wieder aus mehreren Operationen, die die CPU durchführt... ist also nach meiner Auffassung so was Ähnliches wie eine Funktion. Aber der Vergleich ist wirklich nicht gut. Ich wollte damit nur veranschaulichen, dass man nicht immer alle Lagen des Anweisungsflusses kennen muss.
Wir reden hier aber nicht über C++. Wenn wir von Java oder c++ reden würden, wäre ich ja völlig auf deiner Seite, da es dort dir impliziten Getter/Setter nicht gibt.
Nein - les' dir die offiziellen Spezifikationen durch. Die sind als Attribute in den IDLs definiert!
Das mag in Java oder C++ so sein, aber in JS (seit ECMA 5) nicht.
Wie schon gesagt - wir reden hier nicht von C++ oder Java, sondern von JS.
Ja und genau darüber reden wir... also was ist das Problem?
Natürlich kannst du dir ein Interface definieren... du hast nur keinen Compiler, der meckert, wenn du dich nicht daran hältst.
das ist kein interface mehr, bzw. würde ich nicht mal soweit gehen, dass der compiler/interpreter meckern muss, das kann man meiner meinung nach sogar zur laufzeit abfangen. aber man müsste ein interface wenigstens igrendwie beschreiben können.
Wenn du meinst...
OOP ist komplett in JS realisierbar. In JS besteht alles aus Objekten (sogar Funktionen, wodurch man sehr schöne Konstrukte bauen kann). Nur kannst du den klassischen Ansatz über Klassen, Vererbung etc. nicht sauber umsetzen. Der Prototype-Ansatz ist einfach ein anderen.
Da könnte man sich mit JS schon was überlegen. Müsste man hald mal eine Konvention einführen...
Das Flexible an JS ist infach ein Fluch und ein Segen.
Wobei ich die auch dort nie besonders schön fand. Mal ein Java-Beispiel:
public class Item{
private int id;
public void setId(int newId){
id = newId;
}
public int getId(){
return id;
}
}Finde ich nicht. Sie gehen doch in die gleiche Richtung: ich kann im nachhinein die Funktionalität, die im Hintergrund läuft ändern, ohne dass ich an externem Code etwas ändern muss. Nur habe ich eine intutivere, besser verständliche und kürzere Schreibweise dafür.
Ich glaube wir reden aneinander vorbei, weil du beim Begriff oop nur die klassische, von Java geprägte Ansicht von objektorientierter Programmierung meinst. Solange ich meine Programmierung an Objekten und nicht an Daten orietiere, ist es für mich OOP.
Das ist dann aber meiner Meinung nach kein OOP, sondern nur eine nette Art um Namespaces zu definieren.
Stimmt - und genau das ist das Problem, dass die nicht JS, sondern eigentlich Java/C++/... schreiben wollen. Jede Programmiersprache ist einfach etwas anders und man muss sich darauf einstellen. So sollte man z.B. auch nicht versuchen in C OOP zu machen, was auch theoretisch gehen würde...
aber nur durch tricks und selbst dann gibt es noch viele tücken
aber das macht ja noch lange keine oop aus
in js fehlt komplett die möglichkeit der kapselung, eins der wichtigsten merkmale der oop. das bekommt man hin, aber nur über tricks, passt dann aber nicht mit der prototypischen vererbung zusammen, da die nur für public member funktioniert.
nicht wirklich
ja, vermutlich kommt das früher oder später
ob du das weisst/vermutest, ist nicht relevant, hauptsache du kommst nicht ran von außen. der sinn von verborgenen implementierungsdetails ist ja nicht, den anwender im unklaren zu lassen, was dahintersteckt, im gegenteil, die namen der schnittstellenfunktionen sollten schon alles über die funktionalität sagen.
ich sehe nicht das xxx.yyy = 99 kürzer ist als xxx.setYYY(99)
das ist eine nette möglichkeit zur kapselung, und damit ist schon mal ein wichtiger punkt erledigt.
nee, die wollen oop
Tücken hast du in jeder Programmiersprache und, wie ich schon sagte, man kann in JS nicht die klassische Ansicht von OOP eins zu eins abbilden. Das muss man aber auch gar nicht, da JS seinen eigenen Ansatz hat.
Das ist falsch. Du kannst mit Scopes wurderbar Kapseln. Man muss nur wissen, wie man das für seine Zwecke umsetzen muss.
Das ist in der Tat nicht optimal.
Das ist ohne Begründung nur deine Meinung. Begründe das und wir können drüber reden.
In dem Beispiel oben komme ich genauso gut ran, wie wenn die Eigenschaft public wäre.
Dann solltest du dringend zählen üben... 12 (sogar mit Leerzeichen) < 14
Das tut mir leid für dich.
Ja und? Warum muss ich das als Benutzer der Schnittstelle sehen? Das sind Details.
Kapselung ist durch Scopes machbar, Vererbung durch Prototype auch (auch wenn man da anders denken muss als beim klassischen OOP) und Polymorphie ist bei einer schwach typisierten Sprache sinnfrei.