Getter und defekte Kapselung

Beim Lösen von Problemen bin ich auf unerwartetes Verhalten von Gettern gestoßen. In den Vorlesungen hier und sogar in den von IntelliJ IDEA generierten Gettern wird das einfachste Schema verwendet: public final class A { private A field; public A getField() { return field; } public void setField(A field) { this.field = field; } } Wenn das Feld ein primitiver Typ oder String ist, der als Wert übergeben wird, dann ist alles in Ordnung, aber wenn das Objekt als Referenz übergeben wird, Dann stellt sich heraus, dass Sie über den Getter vollen Zugriff auf das Feld erhalten können, wodurch die festgelegte geschützte Zugriffsebene aufgehoben wird. Wenn der Setter eine Gültigkeitsbedingung enthält, kann er durch einen solchen Getter umgangen werden, was die Kapselung verletzt und es wäre richtig, einen Klon des Objekts zu erstellen, um dieses Problem zu vermeiden. Ich verstehe, dass nicht alle Objekte einfach geklont werden können, und wenn dies in der Verantwortung des Programmierers liegt, dann ist es seltsam, warum dies nirgendwo in den Vorlesungen erwähnt wurde. UPD: Ein Getter verstößt als Idee natürlich nicht gegen die Kapselung, aber er muss so geschrieben sein, dass er die Prinzipien von OOP nicht verrät. Das bedeutet, dass ein Getter, wenn er ein Objekt erzeugt, dies so tut, dass der Benutzer es nicht auf andere Weise ändern kann, die in der Klasse angegeben ist. In der Collections-Klasse gibt es eine wunderbare Methode , die eine schreibgeschützte Sammlung erstellt. Dies bringt eine Reihe anderer Einschränkungen mit sich, zum Beispiel die Unmöglichkeit des Sortierens, aber für diesen Fall verfügt diese Klasse über: unmodifiableSortedSet unmodifiableSortedMap und einige weitere, um den Komfort zu erhöhen. public static Collection unmodifiableCollection(Collection c)