1. 객체지향 설계의 보호막, 캡슐화의 개요
정의: 데이터(속성)와 그 데이터를 처리하는 함수(메서드)를 하나로 묶고, 내부 구현 상세를 외부에 숨겨 보호하는 객체지향 프로그래밍(OOP)의 핵심 원리.
필요성: 외부의 잘못된 접근으로 인한 데이터 오염을 방지하고, 모듈 간의 결합도를 낮추어 변경에 유연한 구조를 형성하기 위함.
2. 캡슐화의 핵심 메커니즘: 정보 은닉과 접근 제어
가. 정보 은닉 (Information Hiding)
외부에서 객체 내부의 민감한 상태를 직접 조회하거나 수정하지 못하도록 차단함.
객체는 오직 공개된 메서드(Interface)를 통해서만 소통함.
나. 접근 제어자 (Access Modifier)
| 제어자 | 기호 | 접근 범위 | 상세 설명 |
| private | - | 클래스 내부 | 해당 클래스 내에서만 접근 가능 (최고 보안) |
| default | ~ | 패키지 내부 | 동일 패키지 내 클래스들만 접근 가능 |
| protected | # | 상속 관계 | 상속받은 하위 클래스까지 접근 허용 |
| public | + | 전체 공개 | 어디서든 자유롭게 접근 가능 |
3. 캡슐화 구현의 주요 기법 및 특징
데이터 무결성 보장 (Getter/Setter):
속성은
private으로 설정하고,get,set메서드를 통해 데이터의 유효성을 검증한 후 접근을 허용함.
낮은 결합도와 높은 응집도:
내부 로직이 변경되어도 외부에 노출된 인터페이스가 동일하면 다른 모듈을 수정할 필요가 없음 (Side Effect 최소화).
추상화와의 연계:
사용자는 객체가 '어떻게(How)' 동작하는지 알 필요 없이, '무엇을(What)' 하는지만 알고 인터페이스를 사용함.
4. 캡슐화의 기대효과 및 트레이드오프
| 구분 | 주요 내용 | 세부 효과 |
| 유지보수성 | 변경의 국소화 | 내부 코드 수정 시 영향 범위가 해당 객체로 한정됨 |
| 재사용성 | 모듈 독립성 강화 | 완성도 높은 캡슐화 객체는 다른 프로젝트에 쉽게 이식 가능 |
| 안정성 | 보안성 향상 | 허가되지 않은 데이터 변조를 막아 런타임 오류 방지 |
| 성능/복잡도 | 오버헤드 발생 | 단순 접근 시에도 메서드를 거쳐야 하므로 미세한 성능 저하 가능 |
5. 기술사적 제언: 실무적 관점의 'Tell, Don't Ask' 원칙
상태를 묻지 말고 시켜라: 객체에 데이터를 달라고(Get) 물어본 뒤 외부에서 처리하지 말고, 객체 스스로가 기능을 수행하도록 메서드를 설계하는 것이 진정한 캡슐화의 완성임.
클린 코드와 캡슐화: 무분별한 Getter/Setter 생성은 캡슐화를 약화시킴. 객체가 스스로 책임을 완수할 수 있는 논리적 단위로 설계하는 '책임 주도 설계(RDD)' 관점이 요구됨.
결언: 캡슐화는 단순한 코드 묶기가 아닌 **'자율적인 객체'**를 만드는 과정임. 기술사는 복잡한 대규모 시스템에서 도메인 모델의 일관성을 유지하기 위해 강력한 캡슐화 전략을 수립해야 함.
