Lieber Rolf,
praktisch ist es aber so, dass dieser Schutz in den meisten Fällen wirkungslos ist und eher eine Information für den Programmierer ist: „dies ist nicht für Dich gedacht“. Wer die Vereinbarung einhalten will, tut es, wer nicht, kommt dran vorbei.
man muss hier die Bedeutung von „Schutz“ genauer erklären. Private Eigenschaften und Methoden sind kein Schutz vor Datenausspäherei. Sie sind auch kein Schutz vor Malware-Attacken. Ebensowenig vor Staats- und sonstigen Trojanern (Software). Sie sind als Schutz davor gedacht, dass eine andere Programmkomponente Daten ungewollt manipulieren kann. Mehr auch nicht.
Natürlich sind Zugriffsregeln für ein ordentlich strukturiertes Programm relevant, ich kann aber als Autor von Komponente A nicht verhindern, dass der Autor von B im Zweifelsfall meinen Code kopiert und die private-Flags entfernt oder Getter für private Elemente hinzufügt.
s.o.
Der Benutzer kann mit den Developer Tools ebenfalls jederzeit in die Objekte hineinschauen.
s.o.
Vermutlich ist das einer der Gründe, warum JavaScript lange Zeit keine Sprachelemente dafür anbot.
Nein, das hat meiner Einschätzung nach eher damit zu tun, dass JavaScript an die Leistungsfähigkeit von Prozessoren gekoppelt war, die eine effiziente Sprache erst ermöglichten, als Google damit anfing, einen JIT-Compiler für JavaScript zu bauen. Bis dato war das eine Interpretersprache, deren Ausführung prinzipbedingt so langsam war, dass man kaum so elaborierte Dinge damit tun wollte, dass es den heutigen Sprachumfang überhaupt gebraucht hätte.
Liebe Grüße
Felix Riesterer