😀 책에서 기억하고 싶은 내용을 써보세요.
manager = aPerson.department.manager;
manager = aPerson.managr;
class Person {
get manager() {return this.department.manager;}
배경
- 모듈화 설계를 제대로 하는 핵심은 캡슐화다.
- 캡슐화는 모듈들이 시스템의 다른 부분에 대해 알아야 할 내용을 줄여준다.
- 캡슐화가 잘 되어 있다면 무언가를 변경해야 할 때 고려해야 할 모듈 수가 적어져서 코드를 변경하기가 훨씬 쉬워진다.
- 객체 지향을 처음 배울 때는 캡슐화란 필드를 숨기는 것이라고 배운다. 그러다 경험이 쌓이면서 캡슐화의 역할이 그보다 많다는 사실을 깨닫는다.
서버 객체의 필드가 가리키는 객체(위임 객체)의 메서드를 호출하려면 클라이언트는 이 위임 객체를 알아야 한다. 위임 객체의 인터페이스가 바뀌면 이 인터페이스를 사용하는 모든 클라이언트가 코드를 수정해야 한다.
⇒ 이러한 의존성을 없애려면 서버 자체에 위임 메서드를 만들어서 위임 객체의 존재를 숨긴다.
그러면 위임 객체가 수정되도 서버 코드만 고치면 되며, 클라이언트는 아무런 영향을 받지 않는다.
절차
- 위임 객체의 각 메서드에 해당하는 위임 메서드를 서버에 생성한다.
- 클라이언트가 위임 객체 대신 서버를 호출하도록 수정한다. 하나씩 바꿀 때마다 테스트한다.
- 모두 수정했다면, 서버로부터 위임 객체를 얻는 접근자를 제거한다.
- 테스트한다.
예시
사람과 사람이 속한 부서를 다음처럼 정의했다.
// Person 클래스
constructor(name) {
this._name = name;
}
get name() {return this._name;}
get department() {return this._department;}
set department(arg) {this._department = arg;}
// Department 클래스
get chargeCode() {return this._chargeCode;}
set chargeCode(arg) {this._chargeCode = arg;}
get manager() {return this._manager;}
set manager(arg) {this._manager = arg;}
클라이언트에서 어떤 사람이 속한 부서의 관리자를 알고 싶은 상황
⇒ 그러기 위해서는 부서 객체로부터 얻어와야 한다.
// 클라이언트
manager = aPerson.department.manager;
부서 클래스가 관리자 정보를 제공하는 상황
1️⃣ 이러한 의존성을 줄이려면 클라이언트가 부서 클래스를 볼수 없게 숨기고, 대신 사람 클래스에 간단한 위임 메서드를 만들면 된다.
// Person 클래스
get manager() {return this._department.manager;}
2️⃣ 이제 모든 클라이언트가 이 메서드를 사용하도록 고친다.
// 클라이언트
manager = aPerson.manager;
3️⃣ 클라이언트 코드를 다 고쳤다면 사람 클래스의 department() 접근자를 삭제한다.
🤔 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요.
- 캡슐화를 단순히 이론으로만 배우는게 아니라, 예시와 설명이 담겨 있어서 좋았습니다.
- 이론으로만 배우는데는 상당히 한계가 있는 개념이였습니다.
🔎 궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.
반응형