정보 은닉을 통한 소프트웨어 응집도 극대화: 캡슐화(Encapsulation)의 분석

 

1. 객체지향 설계의 보호막, 캡슐화의 개요

• 정의: 데이터(속성)와 그 데이터를 처리하는 함수(메서드)를 하나로 묶고, 내부 구현 상세를 외부에 숨겨 보호하는 객체지향 프로그래밍(OOP)의 핵심 원리.

• 필요성: 외부의 잘못된 접근으로 인한 데이터 오염을 방지하고, 모듈 간의 결합도를 낮추어 변경에 유연한 구조를 형성하기 위함.

---

2. 캡슐화의 핵심 메커니즘: 정보 은닉과 접근 제어

가. 정보 은닉 (Information Hiding)

• 외부에서 객체 내부의 민감한 상태를 직접 조회하거나 수정하지 못하도록 차단함.

• 객체는 오직 공개된 메서드(Interface)를 통해서만 소통함.

나. 접근 제어자 (Access Modifier)

제어자	기호	접근 범위	상세 설명
private	-	클래스 내부	해당 클래스 내에서만 접근 가능 (최고 보안)
default	~	패키지 내부	동일 패키지 내 클래스들만 접근 가능
protected	#	상속 관계	상속받은 하위 클래스까지 접근 허용
public	+	전체 공개	어디서든 자유롭게 접근 가능

---

3. 캡슐화 구현의 주요 기법 및 특징

1. 데이터 무결성 보장 (Getter/Setter):

   • 속성은 private으로 설정하고, get, set 메서드를 통해 데이터의 유효성을 검증한 후 접근을 허용함.

2. 낮은 결합도와 높은 응집도:

   • 내부 로직이 변경되어도 외부에 노출된 인터페이스가 동일하면 다른 모듈을 수정할 필요가 없음 (Side Effect 최소화).

3. 추상화와의 연계:

   • 사용자는 객체가 '어떻게(How)' 동작하는지 알 필요 없이, '무엇을(What)' 하는지만 알고 인터페이스를 사용함.

---

4. 캡슐화의 기대효과 및 트레이드오프

구분	주요 내용	세부 효과
유지보수성	변경의 국소화	내부 코드 수정 시 영향 범위가 해당 객체로 한정됨
재사용성	모듈 독립성 강화	완성도 높은 캡슐화 객체는 다른 프로젝트에 쉽게 이식 가능
안정성	보안성 향상	허가되지 않은 데이터 변조를 막아 런타임 오류 방지
성능/복잡도	오버헤드 발생	단순 접근 시에도 메서드를 거쳐야 하므로 미세한 성능 저하 가능

---

5. 기술사적 제언: 실무적 관점의 'Tell, Don't Ask' 원칙

• 상태를 묻지 말고 시켜라: 객체에 데이터를 달라고(Get) 물어본 뒤 외부에서 처리하지 말고, 객체 스스로가 기능을 수행하도록 메서드를 설계하는 것이 진정한 캡슐화의 완성임.

• 클린 코드와 캡슐화: 무분별한 Getter/Setter 생성은 캡슐화를 약화시킴. 객체가 스스로 책임을 완수할 수 있는 논리적 단위로 설계하는 '책임 주도 설계(RDD)' 관점이 요구됨.

• 결언: 캡슐화는 단순한 코드 묶기가 아닌 **'자율적인 객체'**를 만드는 과정임. 기술사는 복잡한 대규모 시스템에서 도메인 모델의 일관성을 유지하기 위해 강력한 캡슐화 전략을 수립해야 함.