Gettery i uszkodzona enkapsulacja

Podczas rozwiązywania problemów napotkałem nieoczekiwane zachowanie modułów pobierających. W wykładach tutaj, a nawet w getterach generowanych przez IntelliJ IDEA, używany jest najprostszy schemat: public final class A { private A field; public A getField() { return field; } public void setField(A field) { this.field = field; } } Jeśli pole jest typu pierwotnego lub String, który jest przekazywany przez wartość, to wszystko jest w porządku, ale jeśli obiekt jest przekazywany przez referencję, następnie okazuje się, że za pomocą modułu pobierającego można uzyskać pełny dostęp do pola, co unieważnia ustawiony poziom chronionego dostępu. Jeśli setter zawiera jakikolwiek warunek ważności, to można go ominąć poprzez taki getter, co narusza enkapsulację i słuszne byłoby utworzenie klona obiektu, aby uniknąć tego problemu. Rozumiem, że nie wszystkie obiekty da się łatwo sklonować i jeśli pozostawi się to w gestii programisty, to dziwne, że nigdzie na wykładach o tym nie było wzmianki. UPD: Getter jako pomysł oczywiście nie narusza enkapsulacji, ale musi być napisany w taki sposób, aby nie zdradzić zasad OOP. Oznacza to, że jeśli getter tworzy obiekt, robi to w taki sposób, że użytkownik nie może go zmienić w żaden inny sposób określony w klasie. W klasie Collections istnieje wspaniała metoda , która tworzy kolekcję tylko do odczytu. Narzuca to szereg innych ograniczeń, na przykład brak możliwości sortowania, ale w tym przypadku ta klasa ma: unmodibleSortedSet unmodibleSortedMap i kilka innych, dla większej wygody. public static Collection unmodifiableCollection(Collection c)