bohyeon.dev

Appearance

Chapter 12 - 상속 다루기 ​

인상깊은 문장, 코드들 ​

12.1 메서드 올리기 ​

  • 나중에 다른 서브클래스가 더해질 수도 있으니 Party의 서브클래스가 monthlyCost()를 구현해야 한다는 사실을 알려주는 게 좋을 것이다.
js
get monthlyCost() {
  throw new SubclassResponsibilityError();
}

12.6 타입 코드를 서브클래스로 바꾸기 ​

js
function createEmployee(name, type) {
  return new Employee(name, type);
}

->

js
function createEmployee(name, type) {
  switch (type) {
    case 'engineer':
      return new Engineer(name);
    case 'salesperson':
      return new Salesperson(name);
    case 'manager':
      return new Manager(name);
  }
}

12.7 서브클래스 제거하기 ​

  • 더 이상 쓰이지 않는 서브클래스와 마주하는 프로그래머는 가치 없는 것을 이해하느라 에너지를 낭비할 것이다.

12.8 슈퍼클래스 추출하기 ​

  • 객체 지향을 설명할 때 '상속 구조는 현실 세계에서 활용하는 여러 분류 체계에 기초하여 구현에 들어가기 앞서 부모, 자식 관계를 신중하게 설계해야 한다.'라고 이야기하는 사람이 많다.
  • 하지만 내 경험에 비춰보자면 상속은 프로그램이 성장하면서 깨우쳐가게 되며, 슈퍼클래스로 끌어올리고 싶은 공통 요소를 찾았을 때 수행하는 사례가 잦았다.

12.10 서브클래스를 위임으로 바꾸기 ​

  • 그렇다면 이런 행복한 상황에서 나는 왜 서브클래스를 위임으로 바꾸려 할까? 상속은 한 번만 사용할 수 있는 도구다. 따라서 상속을 사용해야 할 다른 이유가 생긴다면, 그리고 그 이유가 프리미엄 예약 서브클래스보다 가치가 크다고 생각된다면 프리미엄 에약을 (상속이 아닌) 다른 방식으로 표현해야 할 것이다.

12.11 슈퍼클래스를 위임으로 바꾸기 ​

  • 상속을 잘못 적용한 예로는 자바의 스택 클래스가 유명하다.
  • 이상의 이유로 '상속은 절대 사용하지 말라'고 조언하는 사람도 있다. 나는 동의하지 않는다. ... 의미상 적합한 조건이라면 상속은 간단하고 효과적인 메커니즘이다. 이런 상황이 변하여 상속이 더는 최선의 방법이 아니게 되면 언제든 이번 리팩터링을 이용해 슈퍼클래스를 위임으로 바꿀 수 있다.

느낀 점 ​

  • 12.6 타입 코드를 서브클래스로 바꾸기 예제는 Vue.js의 예시로 들면 template에서 분기를 해서 마크업을 나눠주다가, 자식 컴포넌트로 쪼개는 것과 비슷할까? 어떨 때 이렇게 하는게 좋을까?
    • 특정 타입에서만 의미가 있는 값을 사용하는 필드나 메서드가 있을 때?
  • 12.7 더 이상 쓰이지 않는 서브클래스와 마주하는 프로그래머는 가치 없는 것을 이해하느라 에너지를 낭비할 것이다. 컴포넌트도 같다. 리팩터링하거나 변경하려는 공통 메서드를 사용하지 않는 컴포넌트에서 사용중인 경우가 있었다.
  • 12.8 프로그램이 성장하면서 깨우쳐가게 된다는 말이 좋았다.
  • 12.10
    • '상속은 한번만 사용할 수 있는 도구다.' 이런 제약을 두는 것이 복잡도를 낮추는데 도움이 되는 것 같다.
    • 결국 분기를 어떻게 해줄 것인지가 중요해보이는 느낌인데 맞을지는 모르겠다. 언어의 도움을 받아 (상속) 분기를 해주던 것을 수동으로 (위임) 분기를 해주는 것으로 바뀐 것 같다.
    • JSX를 사용해서 클래스를 구현가능하게 했던 React와 다르게 Vue에서는 어차피 자식 컴포넌트를 생성할 수 밖에 없다. 그리고 상속이 그렇게 유효한지 또 모르겠으므로.. 딱히 프런트엔드나 Vue에서 상속을 사용할 일이 없었을 것 같긴 하다.
    • SpeiciesDelegate 슈퍼클래스를 또 생성한 것을 보고, 이렇게까지 해야한다는 데서 클래스에 대한 회의감도 잠시 들었다. 그러나, 객체 지향과 같이 널리 사용되는 개념은 분명 이점이 있을 것이다.
  • 12.11
    • 자바와 같은 언어도 잘못 설계하고 (여전히 못 고친) 사례가 있는데 너무 작은 부분을 완벽하게 하려고 하는건 아닌지 하는 반성. 일단 되게 만든 후 제대로 리팩터링 하는 습관만 들여도.. 엄청 훌륭한 개발자가 되는 것 아닐까?
    • 언제든 슈퍼클래스를 위임으로 바꿀 수 있으니 상속은 자유롭게 사용하라 (한번만)는 말도 좋다.