필드 캡슐화
Field encapsulation컴퓨터 프로그래밍에서 필드 캡슐화는 필드에 직접 액세스하지 않고 필드를 읽거나 쓰기 위해 사용할 수 있는 메서드를 제공합니다.이러한 접근자 메서드는 getX 및 setX(여기서 X는 필드 이름)라고 불리며 뮤테이터 메서드라고도 합니다.일반적으로 접근자 메서드는 퍼블릭 가시성을 가지며 캡슐화되는 필드는 프라이빗 가시성이 주어집니다.이것에 의해, 프로그래머는 코드의 다른 유저가 실행할 수 있는 액션을 제한할 수 있습니다.이름 필드가 캡슐화되지 않은 다음 Java 클래스를 비교합니다.
일반의 학급 Normal Field 클래스 { 일반의 스트링 이름.; 일반의 정적인 무효 주된(스트링[] args) { Normal Field 클래스 예1 = 신규 Normal Field 클래스(); 예1.이름. = "마이네임"; 시스템..나가..인쇄("내 이름은" + 예1.이름.); } } 캡슐화를 사용한 같은 예시를 나타냅니다.
일반의 학급 Encapsulated Field 클래스 { 사적인 스트링 이름.; 일반의 스트링 getName() { 돌아가다 이름.; } 일반의 무효 setName(스트링 새 이름) { 이름. = 새 이름; } 일반의 정적인 무효 주된(스트링[] args) { Encapsulated Field 클래스 예1 = 신규 Encapsulated Field 클래스(); 예1.setName("마이네임"); 시스템..나가..인쇄("내 이름은" + 예1.getName()); } } 첫 번째 예에서는 사용자는 퍼블릭 이름 변수를 자유롭게 사용할 수 있습니다.두 번째 예에서는 getName 메서드와 setName 메서드를 통해서만 필드에 대한 접근을 허용함으로써 프라이빗 이름 변수의 읽기 및 쓰기 방법을 제어할 수 있습니다.
이점
- 데이터의 내부 스토리지 포맷은 숨겨져 있습니다.이 예에서는 제한된 문자 세트를 사용할 경우 8비트 문자를 6비트 코드로 리코딩하여 데이터를 압축할 수 있습니다.예상 데이터 범위를 벗어난 문자를 인코딩하려는 시도는 설정된 루틴에 오류를 던져 처리할 수 있습니다.
- 일반적으로 get 및 set 메서드는 발신자가 적절한 데이터를 전달하고 있고 데이터가 적절하게 저장되어 있다고 가정하는 효율적인 방법과 수신 및 전달된 데이터에 대해 속도가 느리지만 유효성 검사를 수행하는 디버깅 버전 두 가지 버전으로 생성될 수 있습니다.이러한 검출은 루틴(호출 또는 호출) 또는 내부 스토리지 형식을 새로 만들거나 수정할 때 유용합니다.
- 더 큰 구조 내에서 저장된 데이터의 위치가 숨겨질 수 있으므로 데이터를 참조하는 코드를 변경할 필요 없이 이 스토리지를 변경할 수 있습니다.이것은 또한 그러한 변화로 인한 예상치 못한 부작용의 가능성을 감소시킨다.이것은, operating system(OS; operating system)의 일부인 경우, 특히 편리합니다.이 경우, OS의 개발자는 발신자(애플리케이션) 코드를 사용할 수 없습니다.
단점들
서브루틴으로의 액세스에는 데이터에 직접 액세스 할 때는 존재하지 않는 추가 오버헤드가 포함됩니다.고속 범용 프로세서의 폭넓은 가용성에 대한 우려는 낮아지고 있지만, 비교적 느리고 심플한 임베디드 프로세서를 사용하는 일부 실시간 컴퓨팅 시스템 및 시스템을 코딩하는 데는 여전히 중요할 수 있습니다.C++와 같은 일부 언어에서 getter/setter 메서드는 보통 인라인 함수이기 때문에 인라이닝을 수행할 때 코드가 직접 필드 액세스와 동일하게 보입니다.