😀 책에서 기억하고 싶은 내용을 써보세요.

manager = aPerson.department.manager;
manager = aPerson.managr;

class Person {
	get manager() {return this.department.manager;}

 

배경

  • 모듈화 설계를 제대로 하는 핵심은 캡슐화다.
  • 캡슐화는 모듈들이 시스템의 다른 부분에 대해 알아야 할 내용을 줄여준다.
  • 캡슐화가 잘 되어 있다면 무언가를 변경해야 할 때 고려해야 할 모듈 수가 적어져서 코드를 변경하기가 훨씬 쉬워진다.
  • 객체 지향을 처음 배울 때는 캡슐화란 필드를 숨기는 것이라고 배운다. 그러다 경험이 쌓이면서 캡슐화의 역할이 그보다 많다는 사실을 깨닫는다.

서버 객체의 필드가 가리키는 객체(위임 객체)의 메서드를 호출하려면 클라이언트는 이 위임 객체를 알아야 한다. 위임 객체의 인터페이스가 바뀌면 이 인터페이스를 사용하는 모든 클라이언트가 코드를 수정해야 한다.

⇒ 이러한 의존성을 없애려면 서버 자체에 위임 메서드를 만들어서 위임 객체의 존재를 숨긴다.

그러면 위임 객체가 수정되도 서버 코드만 고치면 되며, 클라이언트는 아무런 영향을 받지 않는다.

 

 

 

절차

  1. 위임 객체의 각 메서드에 해당하는 위임 메서드를 서버에 생성한다.
  2. 클라이언트가 위임 객체 대신 서버를 호출하도록 수정한다. 하나씩 바꿀 때마다 테스트한다.
  3. 모두 수정했다면, 서버로부터 위임 객체를 얻는 접근자를 제거한다.
  4. 테스트한다.

 

 

예시

사람과 사람이 속한 부서를 다음처럼 정의했다.

// 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() 접근자를 삭제한다.

 

 

🤔 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요.

  • 캡슐화를 단순히 이론으로만 배우는게 아니라, 예시와 설명이 담겨 있어서 좋았습니다.
    • 이론으로만 배우는데는 상당히 한계가 있는 개념이였습니다.

 

🔎 궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.

  •  
반응형

+ Recent posts