private, wenn es fuer die Implementierung gebraucht wird, aber fuer den Anwender nicht von Belang ist.

protected, wenn es fuer ausserhalb nicht von Interesse ist, aber abgeleitete Klassen den Zugriff durchaus brauchen.

Man faengt mit so wenig wie moeglich an (private) und wenn die Funktionalitaet fuer die Anwendung nicht ausreicht, gibt man mehr frei oder schreibt eine andere Methode, die Benutzung auch bei eingeschraenktem Zugriff erlaubt).

Privat ist dazu da, den Programmierer dazu zu zwingen Getter- und Setterfunktionen zum Bearbeiten der Membervariablen zu verwenden.

Ne, private sollte idealerweise die Existenz der Membervariablen ganz verbergen. Setter/Getter sind manchmal nötig, aber eine 1:1-Beziehung zwischen allen privaten Membervariablen und öffentlichen Methoden ist ebenfalls schlechte Kapselung.

eine 1:1-Beziehung zwischen allen privaten Membervariablen und öffentlichen Methoden ist ebenfalls schlechte Kapselung.

Habe ich denn etwas anderes behauptet?

Wenn du das anders gemeint hast, umso besser

Welches Buch war das in dem eine Formel stand wann eine Methode public oder private sein soll?

Keine Ahnung welches Buch das war.

Wobei es relativ einfach ist.
Wenn man ein Programm entwirft, dann definiert man Klassen, die jeweils eine bestimmte Aufgabe übernehmen.
Das Interface einer Klasse, also sämtliche public Funktionen die sie anbietet, definiert welche "Befehle" man einem Objekt der Klasse geben kann, bzw. welche Dinge man "abfragen" kann.
Und es ergibt sich mehr oder weniger direkt aus der Aufgabe die man der Klasse zugeteilt hat.

Eine Klasse die eine Map darstellt wird also Funktionen haben um Key/Value Paare einzufügen, einen Wert anhand des Keys nachzuschlagen oder zu verändern und um einen Key plus den dazugehörenden Wert zu löschen. Evtl. noch weitere Funktionen mit denen man alle Key/Value Paare auflisten kann oder abfragen wie viele es überhaupt gibt.

Sämtliche weiteren Funktionen die man benötigt um das public Interface zu implementieren, werden private gemacht.

Beim Map Beispiel könnten das Funktionen sein um den Hashcode des Keys zu berechnen, einen zu einem Hashcode passenden freien Slot zu finden, den Hashtable zu vergrössern etc. Bzw. wenn man eine Tree-Map implementiert die ganzen Funktionen die nötig sind um einen balancierten Baum zu verwalten.

Privat ist dazu da, den Programmierer dazu zu zwingen Getter- und Setterfunktionen zum Bearbeiten der Membervariablen zu verwenden.

Sorry, aber so wie du das formuliert hast ist es Bullshit.
private ist dazu da zu verhindern dass Dinge die die Aussenwelt nichts angehen von aussen aufgerufen werden können.
Mit Getter- und Setterfunktionen hat das üblicherweise gar nichts zu tun. Schonmal allein deswegen weil es oft genug gar keine Getter- und Setterfunktionen gibt.

Auch das "zum Bearbeiten der Membervariablen" lässt mich vermuten dass du von objektorientiertem Softwaredesign nicht viel Plan hast. Sich Gedanken über das "Bearbeiten der Membervariablen" zu machen ist nämlich der komplett falsche Ansatz. "Privatangelegenheit" sozusagen, geht keinen was an.

Wenn man eine neue Klasse definiert, oder auch eine bestehende verwendet, sollte es erstmal vollkommen egal sein was diese für Membervariablen hat. Wichtig ist das Interface, das definiert was man mit Objekten dieser Klasse machen kann. Wie das gemacht wird, was es für Membervariablen geben könnte etc., ist dabei alleine Sache der Klasse.

Mr.Long schrieb:

Somit kann man die Art auf welche auf die Variablen zugegriffen wird unabhängig davon ändern, wie man auf Variablen zugreift (man muss im Quelltext weniger ändern).

Den Satz solltest du selbst nochmal lesen. Der ist nämlich totaler Quark.