게터 및 손상된 캡슐화

문제를 해결하는 동안 getter의 예상치 못한 동작을 접했습니다. 여기 강의와 IntelliJ IDEA에서 생성된 게터에서도 가장 간단한 체계가 사용됩니다. public final class A { private A field; public A getField() { return field; } public void setField(A field) { this.field = field; } } 필드가 기본 유형이거나 값으로 전달되는 문자열인 경우 모든 것이 괜찮지만 객체가 참조로 전달되는 경우에는 그런 다음 getter를 통해 필드에 대한 전체 액세스 권한을 얻을 수 있으며, 이는 설정된 보호 액세스 수준을 무효화합니다. setter에 유효성 조건이 포함되어 있으면 그러한 getter를 통해 우회할 수 있으며 이는 캡슐화를 위반하므로 이 문제를 피하기 위해 개체의 복제본을 만드는 것이 옳습니다. 모든 객체가 쉽게 복제될 수는 없다는 점을 이해하며, 이것이 프로그래머의 책임에 맡겨진다면 강의 어디에도 이에 대한 언급이 없는 이유가 이상합니다. UPD: 물론 아이디어로서의 getter는 캡슐화를 위반하지 않지만 OOP 원칙을 배반하지 않는 방식으로 작성되어야 합니다. 이는 getter가 객체를 생성하는 경우 사용자가 클래스에 지정된 다른 방식으로 객체를 변경할 수 없는 방식으로 객체를 생성한다는 것을 의미합니다. Collections 클래스에는 읽기 전용 컬렉션을 생성하는 훌륭한 메서드가 있습니다. 이는 정렬 불가능과 같은 여러 가지 다른 제한 사항을 부과하지만 이 경우 이 클래스에는 더 나은 편의를 위해 unmodifyingSortedSet unmodifyingSortedMap 및 몇 가지 더 많은 제한 사항이 있습니다. public static Collection unmodifiableCollection(Collection c)