Es empfiehlt sich aber immer Public zu verwenden, solange man nicht mit mehrern zusammenarbeitet bzw. Klassen schreibt die andere in ihre Projekte einbauen können.
NEIN. (Ausnahmsweise mal was mit Caps Lock, ja, haut mich...
)
Eines der wichtigsten Prinzipien von OOP (wenn nicht sogar das wichtigste überhaupt) ist das
Geheimnisprinzip. Vereinfacht gesagt: Man macht IMMER ALLES so privat wie möglich.
Eigentlich.
In dem Beispiel sollten die xcoord/ycoord also
private sein.
Eigentlich.
Aber so einfach ist es eben nicht.
Das Beispiel, das du dir ausgesucht hast (Vektormathezeug) ist einerseits toll, weil man da bestimmte OOP-Aspekte schön anwenden kann. Gleichzeitig ist es aber auch unheimlich schwer und wirft wahnsinnig viele Fragen auf, die sich in anderen Fällen nicht stellen. Der Unterschied zu "anderen Fällen" besteht hier in der schier unendlichen Abstrahier- und Erweiterbarkeit, und der engen Verbindung zur Mathematik, die sich
sehr oft sehr gut aber an manchen Stellen auf schmerzhafte Weise
nicht perfekt auf OOP übertragen läßt.
Vielleicht kennst du die javax.vecmath-Bibliothek, die schon so etwas anbietet, was du jetzt dort programmieren willst: Vector3d, Point3d, Matrizen und einige praktische andere Dinge. Dort wurde gegen das oben genannte "heilige Prinzip" verstoßen, und die Koordinaten der Vector3d-Klasse (x,y,z) sind
public. Das ganze stammt aber noch aus einer Zeit, wo man sich dadurch höchstwahrscheinlich Methodenaufrufe (für getter und setter) sparen wollte und sich höhere Effizienz erhofft hat. Heute würde man das vermutlich nicht mehr machen. Tatsächlich wurden in den letzten vecmath-Versionen auch getter und setter eingefügt, wenn auch aus einem anderen Grund - aber die public Fields x,y,z sind nach wie vor vorhanden. Das ist einer der Gründe, weswegen public Fields bei "echter OOP" ein no-go sind: Sie sind immer da, man wird sie nicht mehr los, und sie sind unflexibel.
Insgesamt ist OOP eine Wissenschaft für sich, und was für Leute, die Herausforderungen suchen: Es ist
immer schwer, gut OO zu programmieren (wenn es leicht wäre, würde man versuchen, es besser zu machen, und dann wäre es wieder schwer
).
An diesem Vecmath-Beispiel sieht man schon einen Punkt, wo man OOP zumindest in erster Näherung sinnvoll einsetzen könnte: Vector2d und Point2d könnten von einer Klasse "Tuple2d" erben. Worin unterscheiden sich Point und Vector? Eigentlich nur im Namen, und vielleicht dass man aus zwei Punkten kein Kreuzprodukt oder zwischen zwei Vektoren keinen Abstand berechnen kann. Letzteres wären dann spezielle Methoden in den von Tuple2d (bzw. Tuple3d) abgeleiteten Klassen. Andererseits wäre es eben oft praktisch, wenn Punkte wie Vektoren behandeln und zwischen ihnen ein Kreuzprodukt ausrechnen könnte - das ist dann der Punkt, wo die Mathematik "flexibler" ist, als das, was man "stimmig" mit OOP abbilden kann. Eine Möglichkeit wäre dann eine statische Utility-Methode wie
void computeCrossProduct(Tuple3d t0, Tuple3d t1, Tuple3d cross)
Über weiter gehende Fragen, wie ob die ganzen Klassen dort nicht eigentlich
<3 interfaces
<3 sein sollten, oder ob sie Immutable sein sollten und wie man das dann vernünftig und effizient umsetzt könnte man sich noch viel länger Gedanken machen...
