TL;DR

  • 객체지향의 대표적인 재사용 기법인 상속에 관해 다룹니다. 조금 놀랄 수도 있겠지만 10장의 주제는 코드 재사용을 위해 상속을 사용하지 말라는 것입니다.
  • 객체지향 프로그래밍의 장점 중 하나는 코드를 재사용하기가 용이하다는 것입니다.
  • 전통적인 패러다임에서 코드를 재사용하는 방법은 코드를 복사한 후 수정하는 것입니다.
  • 객체지향은 조금 다른 방법을 취합니다. 객체지향에서는 코드를 재사용 하기 위해 ‘새로운’ 코드를 추가합니다. 객체지향에서 코드는 일반적으로 클래스 안에 작성되기 때문에 객체지향에서 클래스를 재사용하는 전통적인 방법은 새로운 클래스를 추가하는 것입니다.
  • 이번 장에서는 클래스를 재사용하기 위해 새로운 클래스를 추가하는 가장 대표적인 기법인 상속에 관해 살펴봅니다. 재사용 관점에서 상속이나 클래스 안에 정의된 인스턴스 변수와 메서드를 자동으로 새로운 클래스에 추가하는 구현 기법입니다.
  • 객체지향에서는 상속 외에도 코드를 효과적으로 재사용할 수 있는 방법이 한 가지 더 있습니다. 새로운 클래스의 인스턴스 안에 기존 클래스의 인스턴스를 포함시키는 방법으로 흔히 합성이라고 부릅니다.
  • 코드를 재사용하려는 강력한 동기 이면에는 중복된 코드를 제거하려는 욕망이 숨어 있습니다. 따라서 상속에 대해 살펴보기 전에 중복 코드가 초래하는 문제점을 살펴보는 것이 유용할 것입니다.

01. 상속과 중복 코드

  • 중복 코드는 우리를 주저하게 만들뿐만 아니라 동료들을 의심하게 만듭니다. 이것만으로도 중복 코드를 제거해야 할 충분한 이유가 되고도 남겠지만 결정적인 이유는 따로 있습니다.

DRY 원칙

  • 중복 코드는 변경을 방해합니다. 이것이 중복 코드를 제거해야 하는 가장 큰 이유입니다.
  • 중복 코드가 가지는 가장 큰 문제는 코드를 수정하는 데 필요한 노력을 몇 배로 증가시킨다는 것입니다. 우선 어던 코드가 중복인지를 찾아야 합니다. 일단 중복 코드의 묶음을 찾았다면 찾아낸 모든 코드를 일관되게 수정해야 합니다. 모든 중복 코드를 개별적으로 테스트해서 동일한 결과를 내놓는지 확인해야만 합니다. 중복 코드는 수정과 테스트에 드는 비용을 증가시킬뿐만 아니라 시스템과 개발자를 공황상태로 몰아넣을 수도 있습니다.
  • 중복 여부를 판단하는 기준은 변경입니다. 요구사항이 변경됐을 때 두 코드를 함께 수정해야 한다면 이 코드는 중복입니다. 중복 여부를 결정하는 기준은 코드가 변경에 반응하는 방식 입니다.
  • 신뢰할 수 있고 수정하기 쉬운 소프트웨어를 만드는 효과적인 방법 중 하나는 중복을 제거하는 것입니다.
  • DRY(Don’t Repeat Yourself)는 반복하지마라의 첫 글자를 모아 만든 용어로 지식을 중복하지 말라는 것입니다.
    • DRY 원칙은 한번, 단 한번(Once and Only Once) 원칙 또는 단일 지점 제어(Single Point Control) 원칙이라고 부릅니다.
    • 원칙의 이름이 무엇이건 핵심은 코드 안에 중복이 존재해서는 안 된다는 것입니다.

DRY 원칙

  • 모든 지식은 시스템 내에서 단일하고, 애매하지 않고, 정말로 믿을 만한 표현 양식을 가져야 합니다.

중복과 변경

중복 코드 살펴보기

중복 코드 수정하기

  • 많은 코드 더미 속에서 어떤 코드가 중복인지를 파악하는 일은 ㅅ귀운 일이 아닙니다. 중복 코드는 항상 함께 수정돼야 하기 때문에 수정할 때 하나라도 빠트린다면 버그로 이어질 것입니다.
  • 한 발 양보해서 모든 중복 코드를 식별했고 함께 수정했다고 하더라도 더 큰 문제는 주복 코드를 서로 다르게 수정하기가 쉽다는 것입니다.
  • 민첩하게 변경하기 위해서는 중복 코드를 추가하는 대신 제거해야 합니다. 기회가 생길 때마다 코드를 DRY하게 만들기 위해 노력합니다.

타입 코드 사용하기

  • 두 클래스 사이의 중복 코드를 제거하는 한 가지 방법은 크랠스를 하나로 합치는 것입니다. 하지만 타입 코드를 사용하는 클래스는 낮은 응집도와 높은 결합도라는 문제에 시달리게 됩니다.
  • 객체지향 프로그래밍 언어는 타입 코드를 사용하지 않고도 중복 코드를 관리할 수 있는 효과적인 방법인 상속을 제공합니다.

상속을 이용해서 중복 코드 제거하기.

  • 상속을 염두에 두고 설계되지 않은 클래스를 상속을 이용해 재사용하는 것은 생각처럼 쉽지 않습니다. 개발자는 재사용을 위해 상속 계층 사이에 무수히 많은 가정을 세웠을지도 모릅니다. 그리고 그 가정은 코드를 이해하기 어렵게 만들뿐만 아니라 직관에도 어긋날 수 있습니다.
  • 상속을 이용해 코드를 재사용하기 위해서는 부모 클래스의 개발자가 세웠던 가정이나 추론 과정을 정확하게 이해해야 합니다. 이것은 자식 클래스의 작성자가 부모 클래스의 구현 방법에 대한 정확한 지식을 가져야 한다는 것을 의미합니다. 따라서 상속은 결합도를 높입니다. 그리고 상속이 초래하는 부모 클래스와 자식 클래스 사이의 강한 결합이 코드를 수정하기 어렵게 만듭니다.

강하게 결합된 Phone과 NightlyDiscountPhone

  • 자식 클래스가 부모 클래스의 구현에 강하게 결합될 경우 부모 클래스의 변경에 의해 자식 클래스가 영향을 받습니다. 상속을 사용하면 적은 노력으로도 새로운 기능을 쉽고, 빠르게 추가할 수 있습니다. 하지만 그로 인해 커다란 대가를 치러야 할 수도 있습니다.
  • 상속 관계로 연결된 자식 클래스가 부모 클래스의 변경에 취약해지는 현상을 가리켜 취약한 기반 클래스 문제라고 부릅니다. 취약한 기반 클래스 문제는 코드 재사용을 목적으로 상속을 사용할 때 발생하는 가장 대표적인 문제입니다.

상속을 위한 경고 1

  • 자식 클래스의 메서드 안에서 super 참조를 이용해 부모 클래스의 메서드를 직접 호출할 경우 두 클래스는 강하게 결합됩니다. super 호출을 제거할 수 있는 방법을 찾아 결합도를 제거합니다.

02. 취약한 기반 클래스 문제

  • 부모 클래스의 변경에 의해 자식 클래스가 영향을 받는 현상을 취약한 기반 클래스 문제(Fragile Base Class Problem, Brittle Base Class Problem)라고 부릅니다. 이 문제는 상속을 사용한다면 피할 수 없는 객체지향 프로그래밍의 근본적인 취약성입니다.
  • 취약한 기반 클래스 문제는 상속이라는 문맥 안에서 결합도가 초래하는 문제점을 가린키는 용어입니다. 상속 관계를 추가할수록 전체 시스템의 결합도가 높아진다는 사실을 알고 있어야 합니다. 상속은 자식 클래스를 점진적으로 추가해서 기능을 확장하는 데는 용이하지만 높은 결합도로 인해 부모 클래스를 점진적으로 개선하는 것은 어렵게 만듭니다. 최악의 경우에는 모든 자식 클래스를 동시에 수정하고 테스트해야 할 수도 있습니다.
  • 취약한 기반 클래스 문제는 캡슐화를 약화시키고 결합도를 높입니다. 상속은 자식 클래스가 부모 클래스의 구현 세부사항에 의존하도록 만들기 때문에 캡슐화를 약화시킵니다. 이것은 상속이 위험한 이유인 동시에 우리가 상속을 피해야하는 첫 번째 이유입니다.
  • 객체를 사용하는 이유는 구현과 세부사항을 퍼블릭 인터페이스 뒤로 캡슐화할 수 있기 때문입니다. 캡슐화는 변경에 의한 파급효과를 제어할 수 있기 때문에 가치가 있습니다. 객체는 변경될지도 모르는 불안정한 요소를 캡슐화함으로써 파급효과를 걱정하지 않고도 자유롭게 내부를 변경할 수 있습니다.
  • 안타깝게도 상속을 사용하면 부모 클래스의 퍼블릭 인터페이스가 아닌 구현을 변경하더라도 자식 클래스가 영향을 받기 쉬워집니다. 상속 계층의 상위에 위치한 클래스에 가해지는 작은 변경만으로도 상속 계층에 속한 모든 자손들이 급격하게 요동칠 수 있습니다.
  • 객체지향의 기반은 캡슐화를 통한 변경의 통제입니다. 상속은 코드의 재사용을 위해 캡슐화의 장점을 희석 시키고 구현에 대한 결합도를 높임으로써 객체지향이 가진 강력함을 반감시킵니다.

불필요한 인터페이스 상속 문제

  • 퍼블릭 인터페이스에 대한 고려 없이 단순히 코드 재사용을 위해 상속을 이용하는 것은 매우 위험합니다. 객체지향의 핵심은 객체들의 협력입니다. 단순히 코드를 재사용하기 위해 불필요한 오퍼레이션이 인터페이스에 스며들도록 방치해서는 안 됩니다.

상속을 위한 경고 2

  • 상속 받은 부모 클래스의 메서드가 자식 클래스의 내부 구조에 대한 규칙을 깨드릴 수 있습니다.

메서드 오버라이딩의 오작용 문제

  • 주슈아 블로치는 클래스가 상속되기를 원한다면 상속을 위해 클래스를 설계하고 문서화해야 하며, 그렇지 않은 경우에는 상속을 금지시켜야 한다고 주장합니다. 상속이 초래하는 문제점을 보완하면서 코드 재사용의 장점을 극대화 하기 위해서는 조슈아 블로치의 주장에 귀를 기울일 가치가 충분합니다.
    • 우선 클래스에서는 메서드 오버라이딩으로 인한 파급 효과를 분명하게 문서화해야 합니다. 달리 말해, 오버라이딩 가능한 메서드들의 자체 사용(self-use), 즉, 그 메서드들이 같은 클래스의 다른 메서드를 호출하는지에 대해 반드시 문서화 해야 합니다. 이와 반대로, 각각의 public이나 protected 메서드 및 생성자가 어떤 오버라이딩 가능한 메서드를 호출하는지, 어떤 순서로 하는지, 호출한 결과가 다음 처리에 어떤 영향을 주는지에 대해서도 반드시 문서화해야 합니다. 더 일반적으로 말하면 오버라이딩 가능한 메서드를 호출할 수 있는 어떤 상황에 대해서도 문서화 해야 한다는 것입니다.
    • 그러나 잘된 API 문서는 메서드가 무슨일(what)을 하는지 기술해야 하고, 어떻게 하는지(how)를 설명해서는 안 된다는 통념을 어기는 것입니다. 이것은 결국 상속이 캡슐화를 위반함으로써 초래된 불행인 것입니다. 서브 클래스가 안전할수 있게끔 클래스를 문서화하려면 클래스의 상세 구현 내역을 기술해야 합니다.
  • 설계는 트레이드오프 활동이라는 사실을 기억해야 합니다. 상속은 코드 재사용을 위해 캡슐화를 희생합니다. 완벽한 캡슐화를 원한다면 코드 재사용을 포기하거나 상속 이외의 다른 방법을 사용해야 합니다.

상속을 위한 경고 3

  • 자식 클래스가 부모 클래스의 메서드를 오버라이딩 할 경우 부모 클래스가 자신의 메서드를 사용하는 방법에 자식 클래스가 결합될 수 있습니다.

부모 클래스와 자식 클래스의 동시 수정 문제

  • 결합도란 다른 대상에 대해 알고 있는 지식의 양입니다. 상속은 기본적으로 부모 클래스의 구현을 재사용한다는 기본 전제를 따르기 때문에 자식 클래스가 부모 클래스의 내부에 대해 속속들이 알도록 강요합니다. 따라서 코드 재사용을 위한 상속은 부모 클래스와 자식 클래스를 강하게 결합시키기 때문에 함께 수정해야 하는 상황 역시 빈번하게 발생할 수밖에 없는 것입니다.
    • 서브클래스는 올바른 기능을 위해 슈퍼클래스의 세부적인 구현에 의존합니다. 슈퍼클래스의 구현은 릴리스를 거치면서 변경될 수 있고, 그에 따라 서브클래스의 코드를 변경하지 않더라도 깨질 수 있습니다. 결과적으로, 슈퍼클래스의 작성자가 확장될 목적으로 특별히 그 클래스를 설계하지 않았다면 서브클래스는 슈퍼클래스와 보조를 맞춰서 진화해야 합니다.

상속을 위한 경고 4

  • 클래스를 상속하면 결합도로 인해 자식 클래스와 부모 클래스의 구현을 영원히 변경하지 않거나, 자식 클래스와 부모 클래스를 동시에 변경하거나 둘 중 하나를 선택할 수밖에 없습니다.

03. Phone 다시 살펴보기

추상화에 의존하자

  • 자식 클래스가 부모 클래스의 구현이 아닌 추상화에 의존하도록 만들면 두 클래스가 강하게 결합된 문제를 해결할 수 있습니다. 정확하게 말하면 부모 클래스와 자식 클래스 모두 추상화에 의존하도록 수정해야 합니다.
  • 코드 중복을 제거하기 위해 상속을 도입할 때 두 가지 원칙을 따릅니다.
    • 두 메서드가 유사하게 보인다면 차이점을 메서드로 추출합니다. 메서드 추출을 통해 두 메서드를 동일한 형태로 보이도록 만들 수 있습니다.
    • 부모 클래스의 코드를 하위로 내리지 말고 자식 클래스의 코드를 상위로 올립니다. 부모 클래스의 구체적인 메서드를 자식 클래스로 내리는 것보다 자식 클래스의 추상적인 메서드를 부모 클래스로 올리는 것이 재사용성과 응집도 측면에서 더 뛰어난 결과를 얻을 수 있습니다.

차이를 메서드로 추출하라

  • 가장 먼저 할 일은 중복 코드 안에서 차이점을 별도의 메서드로 추출하는 것입니다. 이것은 흔히 말하는 변하는 것으로부터 변하지 않는 것을 분리하라, 또는 ‘변하는 부분을 찾고 이를 캡슐화하라’라는 조언을 메서드 수준에서 적용한 것입니다.

중복 코드를 부모 클래스로 올려라

  • 목표는 모든 클래스들이 추상화에 의존하도록 만드는 것이기 때문에 이 클래스는 추상클래스로 구현하는 것이 적합할 것입니다.
  • 공통 코드를 옮길 때 인스턴스 변수보다 메서드를 먼저 이동시키는 게 편한데, 메서드를 옮기고 나면 그 메서드에 필요한 메서드나 인스턴스 변수가 무엇인지 컴파일 에러를 통해 자동으로 알 수 있기 때문입니다. 컴파일 에러를 바탕으로 메서드와 인스턴스 변수를 이동시키면 불필요한 부분은 자식 클래스에 둔 채로 부모 클래스에 꼭 필요한 코드만 이동시킬 수 있습니다.
  • ‘위로 올리기’ 전략은 실패했더라도 수정하기 쉬운 문제를 발생시킵니다. 문제는 쉽게 찾을 수 있고 쉽게 고칠 수 있습니다. 추상화하지 않고 빼먹은 코드가 있더라도 하위 클래스가 해당 행동을 필요로 할 때가 오면 이 문제는 바로 눈에 띕니다. 모든 하위 클래스가 이 행동을 할 수 있게 만들려면 여러 개의 중복 코드를 양상하거나 이 행동을 상위 클래스로 올리는 수밖에 없습니다. 가장 초보적인 프로그래머라도 중복 코드를 양산하지 말라고 배웠기 때문에 나중에 누가 이 애플리케이션을 관리하든 이 문제는 쉽게 눈에 띕니다. 위로 올리기에서 실수하더라도 추상화할 코드는 눈에 띄고 결국 상위 클래스로 올려지면서 코드 품질이 높아집니다. 하지만 이 리팩터링을 반대 방향으로 진행한다면, 다시 말해 구체적인 구현을 아래로 내리는 방식으로 현재 클래스를 구체 클래스에서 추상 클래스로 변경하려 한다면 작은 실수 한 번으로도 구체적인 행동을 상위 클래스에 남겨 놓게 됩니다.

추상화가 핵심이다

  • 클래스들이 추상화에 의존하게 되면 생기는 장점
    • 공통 코드를 이동시킨 후에 각 클래스는 서로 다른 변경의 이유를 가집니다. 각각 하나의 변경 이유만을 가집니다. 단일 책임 원칙을 준수하기 때문에 응집도가 높습니다.
    • 오직 추상화에만 의존한다면 낮은 결합도를 유지할 수 있습니다.
    • 부모 클래스 역시 자신의 내부에 구현된 추상 메서드를 호출하기 때문에 추상화에 의존한다고 말할 수 있습니다. 의존성 역전 원칙도 준수 합니다.
    • 확장에는 열려 있고 수정에는 닫혀 있기 때문에 개방-폐쇄 원칙 역시 준수 합니다.
  • 상속 계층이 코드를 진화시키는 데 걸림돌이 된다면 추상화를 찾아내고 상속 계층 안에 클래스들이 그 추상화에 의존하도록 코드를 리팩터링합니다. 차이점을 메서드로 추출하고 공통적인 부분은 부모 클래스로 이동합니다.

의도를 드러내는 이름 선택하기

세금 추가하기

  • 클래스라는 도구는 메서드뿐만 아니라 인스턴스 변수도 함께 포함합니다. 따라서 클래스 사이의 상속은 자식 클래스가 부모 클래스가 구현한 행동뿐만 아니라 인스턴스 변수에 대해서도 결합되게 만듭니다.
  • 인스턴스 변수의 목록이 변하지 않는 상황에서 객체의 행동만 변경된다면 상속 계층에 속한 각 클래스들을 독립적으로 진화시킬 수 있습니다. 하지만 인스턴스 변수가 추가되는 경우는 다릅니다. 자식 클래스는 자신의 인스턴스를 생성할 때 부모 클래스에 정의된 인스턴스 변수를 초기화해야 하기 때문에 자연스럽게 부모 클래스에 추가된 인스천스 변수는 자식 클래스의 추기화 로직에 영향을 미치게 됩니다. 결과적으로 책임을 아무리 잘 분리하더라도 인스천스 변수의 추가는 종종 상속 계층 전반에 걸친 변경을 유발합니다.
  • 하지만 인스턴스 초기화 로직을 변경하는 것이 두 클래스에 동일한 코드를 중복 시키는 것보다는 현명한 선택입니다. 8장을 주의깊게 읽었다면 객체 생성 로직이 변경됐을 때 영향을 받는 부분을 최소화하기 위해 노력해야 한다는 사실을 잘 알고 있을 것입니다. 객체 생성 로직의 변경에 유연하게 대응할 수 있는 다양한 방법이 존재합니다. 따라서 객체 생성 로직에 대해 변경을 막기보다는 핵심 로직의 중복을 막습니다. 핵심 로직은 한 곳에 모아 놓고 조심스럽게 캡슐화 해야 합니다. 그리고 공통적인 핵심 로직은 최대한 추상화해야 합니다.
  • 메서드 구현에 대한 결합은 추상 메서드를 추가함으로써 어느 정도 완화할 수 있지만 인스턴스 변수에 대한 잠재적인 결합을 제거할 수 있는 방법은 없습니다. 우리가 원하는 것은 행동을 변경하기 위해 인스턴스 변수를 추가하더라도 상속 계층 전체에 걸쳐 부작용이 퍼지지 않게 막는 것입니다.

04. 차이에 의한 프로그래밍

  • 상속을 사용하면 이미 존재하는 클래스의 코드를 기반으로 다른 부분을 구현함으로써 새로운 기능을 쉽고 빠르게 추가할 수 있습니다. 상속이 강력한 이유는 익숙한 개념을 이용해서 새로운 개념을 쉽고 빠르게 추가할 수 있기 때문입니다.
  • 기존 코드와 다른 부분만을 추가함으로써 애플리케이션의 기능을 확장하는 방법을 차이에 의한 프로그래밍(programming by difference)이라고 부릅니다. 상속을 이용하면 이미 존재하는 클래스의 코드를 쉽게 재사용할 수 있기 때문에 애플리케이션의 점진적인 정의(incremental definition)가 가능해집니다.
  • 차이에 의한 프로그래밍의 목표는 중복 코드를 제거하고 코드를 재사용하는 것입니다. 사실 중복 코드 제거와 코드 재사용은 동일한 행동을 가리키는 서로 다른 용어입니다. 중복을 제거하기 위해서는 코드를 재상용 가능한 단위로 분해하고 재구성해야 합니다. 코드를 재사용하기 위해서는 중복 코드를 제거해서 하나의 모듈로 모아야 합니다. 프로그래밍의 세계에서 중복 코드는 악의 근원입니다. 따라서 중복 코드를 제거하기 위해 최대한 코드를 재사용해야 합니다.

- 코드를 재사용하는 것은 단순히 문자를 타이핑하는 수고를 덜어주는 수준의 문제가 아닙니다. 재사용 가능한 코드란 심각한 버그가 존재하지 않는 코드입니다. 따라서 코드를 재사용하면 코드의 품질은 유지하면서도 코드를 작성하는 노력과 테스트는 줄일 수 있습니다.

  • 객체지향 세계에서 중복 코드를 제거하고 코드를 재사용할 수 있는 가장 유명한 방법은 상속입니다. 기본 아이디어는 간단합니다. 여러 클래스에 공통적으로 포함돼 있는 중복 코드를 하나의 클래스로 모읍니다. 원래 클래스들에서 중복 코드를 제거한 후 중복 코드가 옮겨진 클래스를 상속 관계로 연결합니다. 코드를 컴파일하면 무대 뒤에서 마법이 일어나 상속 관계로 연결된 코드들이 하나로 합쳐집니다. 따라서 상속을 사용하면 여러 클래스 사이에서 재사용 가능한 코드를 하나의 클래스 안으로 모을 수 있습니다.
  • 상속은 강혁한 도구입니다. 상속을 이용하면 새로운 기능을 추가하기 위해 직접 구현해야 하는 코드의 양을 최소화 할 수 있습니다. 상속은 너무나도 매력적이기 때문에 객체지향 프로그래밍에 갓 입문한 프로그래머들은 상속의 매력에 도취된 나머지 모든 설계에 상속을 적용하려고 시도합니다.
  • 시간이 흐르고 객체지향에 대한 이해가 깊어지면서 사람들은 코드를 재사용하기 위해 맹목적으로 상속을 사용하는 것이 위험하다는 사실을 깨닫기 시작했습니다. 상속이 코드 재사용이라는 측면에서 매우 강력한 도구인 것은 사실이지만 강력만 만큼 잘못 사용할 경우에 돌아오는 피해 역시 크다는 사실을 뼈저리게 경험한 것입니다. 상속의 오용과 남용은 애플리케이션을 이해하고 확장하기 어렵게 만듭니다. 정말로 필요한 경우에만 상속을 사용합니다.
  • 상속은 코드 재사용과 관련된 대부분의 경우에 우아한 해결 방법이 아닙니다. 객체지향에 능숙한 개발자들은 상속의 단점을 피하면서도 코드를 재사용할 수 있는 더 좋은 방법이 있다는 사실을 알고 있습니다. 바로 합성입니다.

참고