4주차: 7장 캡슐화

[choisohyun]

목차명	질문	답변
7.1	1 @choisohyun	3 @blan19
7.2	4 @LastCow9000	5 @w00khyung
7.3	3 @blan19	1 @choisohyun
7.4	2 @RAINBOWJYP	7 @BEMELON
7.5	5 @w00khyung	8 @hamo-o
7.6	7 @BEMELON	6 @suojae
7.7	6 @suojae	4 @LastCow9000
7.8-7.9	8 @hamo-o	2 @RAINBOWJYP

참고자료

• https://github.com/365kim/refactoring-2nd-edition
• https://github.com/emilybache/Tennis-Refactoring-Kata
• https://github.com/emilybache/GildedRose-Refactoring-Kata
• https://github.com/emilybache/Yatzy-Refactoring-Kata

[BEMELON]

7.6

Q. 클래스 인라인은 반댓말은 무엇이고. 왜 하는 걸까요?

[suojae]

• 클래스 인라인의 반대는 클래스 추출하기 입니다
• SOLID 원칙에 따라 클래스는 하나의 책임을 가지고 캡슐화하는 것이 바람직합니다
• 만약 클래스가 너무 많은 책임을 가지고 있다면 책임을 분리시켜 단일책임원칙을 준수하는 클래스들을 만드는 리팩토링을 진행하는 것이 바람직합니다.

[w00khyung]

7.5

Q. 메서드와 데이터가 많은 클래스를 왜 분리하는 게 좋을까요? 어떤 기준에서 분리할 수 있을까요?

[hamo-o]

A.
분리해야 하는 이유

• 메서드와 데이터가 많은 클래스는 이해하기 쉽지 않기 때문입니다.
• 또한 단일 책임 원칙(SRP) - "모든 클래스는 단 하나의 책임만 가져야 한다" 에도 어긋날 수 있습니다.

분리 기준

• 일부 데이터와 메서드를 따로 묶을 수 있다면 분리해야 합니다.
• 따로 분리하고 싶은 부분을 제거해도 다른 필드, 메서드가 논리적으로 문제가 없다면 분리가 가능합니다.
• 클래스에서 파생된 서브클래스를 만드는데, 확장될 기능의 종류에 따라 서브클래스를 만드는 방식이 달라진다면 본 클래스부터 나눠야 합니다.

[suojae]

7.7

Q1. Hide Delegate 패턴을 사용하면 클래스 간 결합도를 줄일 수 있는데, 이 패턴을 사용해야 하는 상황과 그렇지 않은 상황의 기준은 무엇인가요?

[LastCow9000]

A1. 클라이언트에게 위임 객체의 존재를 숨기고 싶은 것이 얼마나 중요한가가 기준입니다.

[choisohyun]

7.1 레코드 캡슐화하기

Q. 중첩된 레코드를 캡슐화하는 방법을 설명해 주세요. 쓰기와 읽기의 방법을 각각 설명해 주세요.

[blan19]

중첩된 레코드의 경우에는 뎁스가 복잡한 경우가 많습니다.
그럴경우엔 먼저 간단한 레코드 캡슐화처럼 변수 캡슐화부터 진행하지만, 복잡한 레코드의 구조를 표현하는 클래스를 사용하여 캡슐화를 진행할 수 있습니다.
게터와 세터 같은 경우는 데이터 구조를 표현하는 클래스를 사용해 옮기는 방법으로 처리할 수 있으며, 게터 같은 경우는 재귀적 캡슐화, 실제 데이터 제공 등의 방법이 추가로 존재합니다

[LastCow9000]

4번 질문

7.2

Q1. 컬렉션을 캡슐화한 클래스에서 컬렉션을 반환할 때 적절한 getter 함수를 정의해보세요.

Class TimeList {
  constructor(times){
    this._timeList = times;
  }
  
  get timeList(){
   //do something...
  }
}

Q2. 왜 위와 같이 해야 할까요?

[w00khyung]

A. 컬렉션 게터를 수정해서 원본 내용을 수정할 수 없는 읽기전용 프락시나 복제본을 반환하게 합니다.

class TimeList {
  constructor(times) {
    this._timeList = times;
  }

  get timeList() {
    // 복사본을 반환하여 외부에서 원본을 수정하지 못하도록 보호
    return this._timeList.slice();
  }
}

[blan19]

7.3

Q. 기본형이 늘어난다면 어떠한 단점이 노출될까요?

Q.기본형을 객체로 바꾼다면 무슨 장점이 있나요?

[choisohyun]

A1. 초기에는 기본형이 늘어나도 큰 차이가 없습니다. 하지만 나중에 포매팅이나 지역 코드 추출 같은 특별한 동작이 추가되는 경우, 중복 코드가 늘어나서 사용할 때마다 노력이 들게 됩니다.

A2. 처음에는 기본형 데이터를 감싼 것과 큰 차이가 없어 효과가 미미합니다.
나중에 특별한 동작이 필요해지면 이 클래스에 추가하면 되기 때문에 점점 유용한 도구와 코드베이스가 됩니다. 또한 메서드에 동작을 추가하면 클라이언트 코드를 더 의미 있게 작성할 수 있게 됩니다. (o.priority === 'high' -> o.prioity.higherThan(new Priority('normal')))

[RAINBOWJYP]

7.4

---

Q1. 함수안에서 어떤 코드의 결과값을 뒤에서 다치 참조할 목적으로 임시 변수를 쓰기도 하는데요. 임시 변수를 사용하면 좋은 점이 무엇이 있나요?
Q2. 임시 변수를 활용한 리팩터링이 적절치 못한 케이스는 무엇이 있을까요?

[BEMELON]

Q1. 결과 값에 의미를 부여하고, 재사용할 수 있다는 점이 장점입니다 !
Q2. 계산값이 아닌 특정 시점에서의 값을 보여주는 경우(Snapshot)에는 부적절합니다!

[hamo-o]

8번 질문 (7.8-7.9)

Q1. 아래 코드에서 중개자를 제거하도록 리팩터링한 코드를 작성해보세요.

class Department {
  manager;
  constructor() {
    this.manager = "관리자입니다";
  }

  get manager() {
    return this.manager;
  }
}

class Person {
  department;

  constructor() {
    this.department = new Department();
  }

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

const person = new Person();
const manager = person.manager;
console.log(manager);

Q2. 알고리즘을 교체하기 전 선행되어야 하는 작업은 무엇일까요?

[RAINBOWJYP]

A1. 질문자님 모르겠습니다... 클래스 어려워요. 우선 department 필드가 노출되도록 했는데 Department 클래스는 고쳐진게 없습니다... 정답이 뭔가요ㅠㅠ

class Department {
  manager;
  constructor() {
    this.manager = "관리자입니다";
  }

  get manager() {
    return this.manager;
  }
}

class Person {
  department;

  constructor() {
    this.department = new Department();
  }

  get manager() {
    return this.manager;
  }
}

const person = new Person();
const manager = person.department.manager;
console.log(manager);

A2.

[hamo-o]

제가 접두사를 붙이지 않아서 약간 혼동이 있었을 수도 있을 것 같네요!
살짝 수정해서 올려봅니닷

[문제]

class Department {
  #manager;

  constructor() {
    this.#manager = "관리자입니다";
  }

  get manager() {
    return this.#manager;
  }
}

class Person {
  #department;

  constructor() {
    this.#department = new Department();
  }

  get manager() {
    return this.#department.manager;
  }
}

const person = new Person();
const manager = person.manager;
console.log(manager);

[정답]

class Department {
  #manager;

  constructor() {
    this.#manager = "관리자입니다";
  }

  get manager() {
    return this.#manager;
  }
}

class Person {
  #department;

  constructor() {
    this.#department = new Department();
  }

  get department() {
    return this.#department;
  }
}

const person = new Person();
const manager = person.department.manager;
console.log(manager);

Department 클래스는 수정 사항이 없는 게 맞고, 책에 나와있는대로 아래와 같이 리팩터링 해볼 수 있을 것 같아요!

1. Person 클래스에서 직접 department(위임 객체) 를 얻는 게터를 만듭니다.
2. person.department.manager로 직접 객체를 사용하도록 수정합니다.
3. 중개자 역할을 하는 manager() 메서드를 삭제합니다.

[RAINBOWJYP]

제가 작성한거엔 Department에도 manager 메서드, Person에도 manager메서드가 생겨버려서 이상했는데 정답보니까 위임메서드를 삭제하는 절차가 부족했네요. 감사합니다.