nicht angemeldet
Noch einmal die Links, die ich bereits gepostet habe:
Selbst dort finde ich "The main reason is that a programmer himself wants to get access to the encapsulated (please notice, I’m specifically not using term “hidden”) data. And if these data will be somehow incorrectly changed or there will be any error — the full responsibility for this is completely on the programmer, but not simply a “typing error” or “someone has casually changed some field”. But if such cases become frequent, we may nevertheless note a bad programming practice and style, since usually it’s the best to “talk” with objects only via public API." womit eigentlich alles gesagt ist.
Und meine Persönliche Erfahrung sagt mir, daß auf alles, was nicht gekapselt ist, auch aus irgendeinem Grund jemand zugreift.
Dann wird ein Balkon nach dem anderen an ein Objekt gebaut. Sind die Daten gekapselt, muss jemand der darauf Zugriff haben möchte mit dem Entwickler reden. Dann kann man zusammen entscheiden, ob es sinnvoll ist diese in der Schnittstelle nach außen zu geben, oder ob derjenige nicht eigentlich versucht eine Funktionalität außen rum zu frickeln, die eigentlich an das Objekt gehört. Nur als ein Beispiel.
Sprachen wie Ruby und Python haben einfach keine effektive Kapselung.
Das mag sein, ist dann aber eine Schwachstelle der Sprache.
Soweit ich weiß, gibt es bei C# und Java ebenfalls eine Möglichkeit, die Kapselung zu umgehen (Wikipedia).
Ich weiß es nicht, aber da dort auch das C++ friend mit in der Liste steht, bin ich skeptisch, daß man damit wirklich von außen Zugriff auf gekapselte Daten bekommt. Gerade friend im C++ ist ja nicht dazu da, die Kapselung zu umgehen, sondern sie zu erhöhen, indem eine Methode nicht öffentlich gemacht werden muß, sondern einem speziellen Objekt Zugriff auf die Interna gestattet wird. Das ist auch nicht gut und auch immer anders lösbar, aber ein Kompromiss den man eingehen kann um größere Umstruckturierungen zu vermeiden, weil die Zeit fehlt.
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