ch12

⬅️ 11장 | 1장 ➡️

12장 상속 다루기

• 12.1 메서드 올리기
• 12.2 필드 올리기
• 12.3 생성자 본문 올리기
• 12.4 메서드 내리기
• 12.5 필드 내리기
• 12.6 타입 코드를 서브클래스로 바꾸기
• 12.7 서브클래스 제거하기
• 12.8 슈퍼클래스 추출하기
• 12.9 계층 합치기
• 12.10 서브클래스를 위임으로 바꾸기
• 12.11 슈퍼클래스를 위임으로 바꾸기

Note

'상속 다루기' 챕터는 다음 질문을 중심으로 읽어나가시면 좋습니다.

1. 언제 상속해야 하는가
2. 슈퍼클래스와 서브클래스의 요소를 어떻게 정리해야 하는가
3. 상속을 오용했다면 어떤 대안이 있는가

12.1 메서드 올리기

p.476

메서드 올리기를 적용하기 가장 쉬운 상황은 메서드들의 본문 코드가 똑같을 때다. 이럴 땐 그냥 복사해 붙여넣으면 끝이다.

p.477

메서드 올리기를 적용하기에 가장 이상하고 복잡한 상황은 해당 메서드의 본문에서 참조하는 필드들이 서브클래스에만 있는 경우다. 이런 경우라면 필드들 먼저 슈퍼클래스로 올린 후에 메서드를 올려야 한다.

💡 의견

• 템플릿 메서드 만들기: https://refactoring.com/catalog/formTemplateMethod.html

12.2 필드 올리기

p.479

서브클래스들이 독립적으로 개발되었거나 뒤늦게 하나의 계층구조로 리펙터링된 경우라면 일부 기능이 중복되어 있을 때가 왕왕 있다. 특히 필드가 중복되기 쉽다. 필드들이 비슷한 방식으로 쓰인다고 판단되면 슈퍼클래스로 끌어올리자. 이렇게 하면 두 가지 중복을 줄일 수 있다. 첫째, 데이터 중복 선언을 없앨 수 있다. 둘째, 해당 필드를 사용하는 동작을 서브클래스에서 슈퍼클래스로 옮길 수 있다.

12.3 생성자 본문 올리기

p.481

서브클래스들에서 기능이 같은 메서드들을 발견하면 함수 추출하기와 메서드 올리기를 차례로 적용하여 말끔히 슈퍼클래스로 옮기곤 한다. 그런데 그 메서드가 생성자라면 스텝이 꼬인다. 생성자는 할 수 있는 일과 호출 순서에 제약이 있기 때문에 조금 다른 식으로 접근해야 한다.

12.4 메서드 내리기

p.485

특정 서브클래스 하나(혹은 소수)와만 관련된 메서드는 슈퍼클래스에서 제거하고 해당 서브클래스(들)에 추가하는 편이 깔끔하다. 다만, 이 리펙터링은 해당 기능을 제공하는 서브클래스가 정확히 무엇인지를 호출자가 알고 있을 때만 적용할 수 있다.

12.5 필드 내리기

p.486

서브클래스 하나(혹은 소수)에서만 사용하는 필드는 해당 서브클래스(들)로 옮긴다.

💡 의견

• 왼쪽 예문에는 private이었는데 오른쪽 예문에선 왜 protected가 되었을까요? 🤔
• 캡슐화가 중요하기 때문에 보통 private으로 선언하고 게터와 세터를 사용하는데 서브클래스로 필드를 옮겼으므로 슈퍼클래스에서 접근이 가능하도록 protected로 선언한 것 같습니다. protected 키워드로 선언한 필드는 같은 패키지 또는 서브클래스에서 접근이 가능합니다.
• 키워드 protected (TypeScript) https://www.typescriptlang.org/docs/handbook/2/classes.html#protected

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

p.487

소프트웨어 시스템에서는 비슷한 대상들을 특정 특성에 따라 구분해야 할 때가 자주 있다. 이런 일을 다루는 수단으로는 타입 코드Type Code 필드가 있다. 타입코드는 프로그래밍 언어에 따라 열거형이나 심볼, 문자열, 숫자 등으로 표현하며, 외부 서비스가 제공하는 데이터를 다루려 할 때 딸려오는 일이 흔하다. 타입 코드만으로도 특별히 불편한 상황은 별로 없지만 그 이상의 무언가가 필요할 때가 있다. 여기서 '그 이상'이라 하면 바로 서브클래스를 가리킨다. 서브클래스는 두 가지 면에서 특히 매력적이다. 첫째, 조건에 따라 다르게 동작하도록 해주는 다형성을 제공한다. 두 번째 매력은 특정 타입에서만 의미가 있는 값을 사용하는 필드나 메서드가 있을 때 발현된다.

💡 의견

• 디자인패턴
  • 상태 패턴: https://refactoring.guru/ko/design-patterns/state
  • 전략 패턴: https://refactoring.guru/ko/design-patterns/strategy
• 쿼리 빌더도 유사한 디자인 패턴을 사용하는 걸까요?
  • 빌더 패턴: https://refactoring.guru/ko/design-patterns/builder
• 전략이나 상태에 따라 컨텍스트를 바꾼다는 점이 OAuth를 떠올리게 합니다.

12.7 서브클래스 제거하기

p.495

서브클래스로 만든 변종이 다른 모듈로 이동하거나 완전히 사라지기도 하면서 가치가 바래지기도 한다. 서브클래스는 결국 한 번도 활용되지 않기도 하며, 때론 서브클래스를 필요로 하지 않는 방식으로 만들어진 기능에서만 쓰이기도 한다. 더 이상 쓰이지 않는 서브클래스와 마주하는 프로그래머는 가치 없는 것을 이해하느라 에너지를 낭비할 것이다. 이런 정도까지 되면 서브클래스를 슈퍼클래스의 필드로 대체해 제거하는 게 최선이다.

12.8 슈퍼클래스 추출하기

p.502

슈퍼클래스 추출하기의 대안으로는 클래스 추출하기가 있다. 어느 것을 선택하느냐는 중복 동작을 상속으로 해결하느냐 위임으로 해결하느냐에 달렸다.

12.9 계층 합치기

p.507

계층구조도 진화하면서 어떤 클래스와 그 부모가 너무 비슷해져서 더는 독립적으로 존재해야 할 이유가 사라지는 경우가 생기기도 한다. 바로 그 둘을 하나로 합쳐야 할 시점이다.

미래를 생각하여 더 적합한 이름의 클래스를 남기자. 둘 다 적절치 않다면 임의로 하나를 고른다.

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

💡 의견

• 상속은 is-a 관계일 경우 사용하고, 합성(위임)은 has-a 관계일 때 사용합니다.
• 결합도는 상속(inheritance) > 위임(delegation) > 합성(composition) 순으로 높다고 합니다.

p.508

하지만 상속에는 단점이 있다. 가장 명확한 단점은 한 번만 쓸 수 있는 카드라는 것이다.

예컨대 사람 객체의 동작을 '나이대'와 '소득 수준'에 따라 달리 하고 싶다면 서브클래스는 젊은이와 어르신이 되거나, 혹은 부자와 서민이 되어야 한다. 둘 다는 안 된다.

💡 의견

• Java, JavaScript는 다중 상속을 지원하지 않으며, C++은 다중 상속을 지원한다.
• 다중상속은 상속 받은 필드나 메서드명이 동일할 경우 문제가 발생할 수 있다.
• 자바스크립트는 다중상속을 지원하지 않는다. (관련 포스팅)

p.509

또 다른 문제로, 상속은 클래스들의 관계를 아주 긴밀하게 결합한다.

(클래스) 상속보다는 (객체) 컴포지션을 사용하라!

p.512

상속은 한 번만 사용할 수 있는 도구다. 따라서 상속을 사용해야 할 다른 이유가 생긴다면, 그리고 그 이유가 프리미엄 예약 서브클래스보다 가치가 크다고 생각된다면 프리미엄 예약을 (상속이 아닌) 다른 방식으로 표현해야 할 것이다. 또한, 기본 예약에서 프리미엄 예약으로 동적으로 전환할 수 있도록 해야 할 수도 있다.

p.517

자바스크립트에서는 객체에 존재하지 않는 속성에 접근하려 하면 undefined를 반환하므로 앞의 코드도 그렇게 처리했다.

class Booking {
  // ...
  get hasDinner() {
    return this._premiumDelegate ? this._premiumDelegate.hasDinner : undefined;
  }
}

💡 의견

• 경진: 위의 코드에서는 undefined를 반환해주었는데 저였다면 빈 값을 명시적으로 나타내는 null을 사용했을 것 같습니다. 다른 분들은 undefined와 null의 사용을 구분하는 기준이 있나요?
• 이수: 위의 코드에서는 PremiumBooking과 달리 Booking에는 hasDinner라는 메서드 자체가 존재하지 않았으므로 undefined를 반환한 것 같습니다.
• 혜수: Optional Chaining을 사용해서 this._premiumDelegate?.hasDinner로 축약할 수도 있을 것 같습니다.

💡 의견

• 이수: React도 합성 모델을 지원합니다. (링크)
• 경진: Vue의 slots과 비슷한 것 같습니다.

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

p.529

상속을 잘못 적용한 예로는 자바의 스택 클래스가 유명하다.

리스트의 연산 중 스택에는 적용되지 않는 게 많음에도 그 모든 연산이 스택 인터페이스에 그대로 노출되는 게 아닌가! 이보다는 스택에서 리스트 객체를 필드에 저장해두고 필요한 기능만 위임했다면 더 멋졌을 것이다.

제대로 된 상속이라면 서브클래스가 슈퍼클래스의 모든 기능을 사용함은 물론, 서브클래스의 인스턴스를 슈퍼클래스의 인스턴스로도 취급할 수 있어야 한다.

p.530

이름과 엔진 크기 등을 속성으로 갖는 자동차 모델 클래스(타입)가 있다고 하자. 그러면 여기에 차량 식별 번호와 제조일자 메서드를 더하면 물리적인 자동차(인스턴스)를 표현하는 데 재활용할 수 있을 거라 착각할 수 있다. 이는 흔하고 미묘한 모델링 실수로, 내가 타입-인스턴스 동형이의어^{type-instance homonym}라고 부르는 것이다.

💡 의견

• 경진: 논리적인 모델 클래스와 물리적인 인스턴스를 혼용하지 말라는 의미로 이해했는데, 혼자 구현했더라면 재활용했을 것 같아서 사실 무슨 말인지 잘 모르겠습니다.

슈퍼 서브/클래스는 강하게 결합된 관계라서 슈퍼클래스를 수정하면 서브클래스가 망가지기 쉽기 때문이다.

위임의 기능을 이용할 호스트의 함수 모두를 전달 함수^{forwarding function}으로 만들어야 한다는 점이다.

💡 의견

• 경진: 전달 함수는 함수에 인자를 전달하면서 함수를 호출하는 로직을 가진 함수를 말하는 것 같습니다.
• 혜수: p.522와 같이 '위임을 위해 호출만 하는 함수'를 말하는 것 같습니다.

class Bird {
  // ...
  selectSpeciesDelegate(data) {
    switch (data.type) {
      case "유럽 제비":
        return new EuropeanSwallowDelegate();
      case "아프리카 제비":
        return new AfricanSwallowDelegate(data);
      case "노르웨이 파랑 앵무":
        return new NorwegianBlueParrotDelegate(data);
      default:
        return null;
    }
  }
}

⬅️ 11장 | ⬆️ 위로 | 1장 ➡️