12장 상속 다루기

[fkdl0048]

12. 상속 다루기

마지막 장..!

이번 장에선 객체 지향 프로그래밍에서 가장 유명한 특성인 상속을 다룬다.

다른 강력한 메커니즘처럼 이 역시 유용한 동시에 오용하기 쉽다.

더욱이 상속은 발등에 불이 떨어져서야 잘못 사용했음을 인지하는 경우가 많다.

12.1 메서드 올리기

public class Employee {...}

public class Salesperson : Employee
{
    public GetName() {...}
}

public class Engineer : Employee
{
    public GetName() {...}
}

public class Employee
{
    public GetName() {...}
}

public class Salesperson : Employee {...}

public class Engineer : Employee {...}

배경

중복 코드 제거는 중요하다.

중복된 두 메서드가 당장은 문제없이 동작할지라도 미래에는 벌레가 꼬이는 음쓰로 전락할 수 있다.

무언가 중복되었다는 것은 한쪽의 변경이 다른 쪽에는 반영되지 않을 수 있다는 위험을 항상 수반한다.

그런데 일반적으로 중복을 찾기가 그리 쉽지 않다는 게 문제다.

메서드 올리기를 적용하기 가장 쉬운 상황위 위와 같은 상황이다.

이럴 때는 그냥 복사해 붙여넣으면 끝나지만 실제로는 이렇게 단순한 경우는 적다.

테스트를 얼마나 잘 만들었느냐에 크게 의존하는 방법이다.

그래서 차이점을 찾는 방법이 효과가 좋다.

테스트에서 놓친 동작까지 알게 해주는 경우가 자주 있기 때문이다.

메서드 올리기 리팩터링을 적용하려면 선행 단계를 거쳐야 할 때가 많다.

예컨대 서로 다른 두 클래스의 두 메서드를 각각 매개변수화하면 궁극적으로 같은 메서드가 되기도 한다.

이런 경우에 가장 적은 단계를 거쳐 리팩터링하려면 각각의 함수를 매개변수화한 다음 메서드를 상속 계층의 위로 올리면 된다.

반면, 메서드 올리기를 적용하기에 가장 이상하고 복잡한 상황은 해당 메서드의 본문에서 참조하는 필드들이 서브클래스에만 있는 경우다.

이런 경우라면 필드들 먼저 슈퍼클래스로 올린 후에 메서드를 올려야 한다.

두 메서드의 전체 흐름은 비슷하지만 세부 내용이 다르다면 템플릿 메서드 만들기를 고려해보자.

절차

• 똑같이 동작하는 메서드인지 면밀히 살펴본다.
• 메서드 안에서 호출하는 다른 메서드와 참조하는 필드들을 슈퍼클래스에서도 호출하고 참조할 수 있는지 확인한다.
• 메서드 시그니처가 다르다면 함수 선언 바꾸기로 슈퍼클래스에서 사용하고 싶은 형태로 통일한다.
• 슈퍼클래스에 새로운 메서드를 생성하고, 대상 메서드의 코드를 붙여넣는다.
• 정적 검사를 수행한다.
• 서브클래스 중 하나의 메서드를 제거한다.
• 테스트한다.
• 모든 서브클래스의 메서드가 없어질 때까지 다른 서브클래스의 메서드를 하나씩 제거한다.

12.2 필드 올리기

public class Employee {...}

public class Salesperson : Employee
{
    private string name;
}

public class Engineer : Employee
{
    private string name;
}

public class Employee
{
    private string name;
}

public class Salesperson : Employee {...}

public class Engineer : Employee {...}

배경

서브클래스들이 독립적으로 개발되었거나 뒤늦게 하나의 계층구조로 리팩터링된 경우라면 일부 기능이 중복되어 있을 때가 왕왕 있다.

특히 필드가 중복되기 쉽다.

이런 필드들은 이름이 비슷한 게 보통이지만, 항상 그런 것은 아니다.

그래서 어떤 일이 벌어지는지 알아내려면 필드들이 어떻게 이용되는지 분석해봐야 한다.

분석 결과 필드들이 비슷한 방식으로 쓰인다고 판단되면 슈퍼클래스로 끌어올린다.

이렇게 하면 두 가지 중복을 줄일 수 있다.

첫째, 데이터 중복 선언을 없앨 수 있다.

둘째, 해당 필드를 사용하는 동작을 서브클래스에서 슈퍼클래스로 옮길 수 있다.

동적 언어 중에는 필드를 클래스 정의에 포함시키지 않는 경우가 많다.

그 대신 필드에 가장 처음 값이 대입될 때 등장한다.

이런 경우라면 필드를 올리기 전에 반드시 생성자 본문부터 올려야 한다.

절차

• 후보 필드들을 사용하는 곳 모두가 그 필드들을 똑같은 방식으로 사용하는지 면밀히 살핀다.
• 필드들의 이름이 각기 다르다면 똑같은 이름으로 바꾼다.
• 슈퍼클래스에 새로운 필드를 생성한다.
• 서브클래스의 필드들을 제거한다.
• 테스트한다.

12.3 생성자 본문 올리기

public class Party {...}

public class Employee : Party
{
    public Employee(string name, string id, int monthlyCost) : base()
    {
        this.name = name;
        this.id = id;
        this.monthlyCost = monthlyCost;
    }
}

public class Party
{
    public Party(string name) 
    {
        this.name = name;
    }
}

public class Employee : Party
{
    public Employee(string name, string id, int monthlyCost) : base(name)
    {
        this.id = id;
        this.monthlyCost = monthlyCost;
    }
}

사실 C#은 기본적으로 생성자를 호출할 때 부모의 생성자를 호출하기에 매개변수가 없다면 부모의 오버로딩된 생성자가 아니라면 base를 사용할 이유가 없긴 하다.

배경

생성자는 다루기 까다롭다.

일반 메서드와 달라서 생성자가 하는 일에 제약을 두는 것이 좋다.

서브클래스들에서 기능이 같은 메서드들을 발견하면 함수 추출하기와 메서드 올리기를 차례로 적용하여 말끔히 슈퍼클래스로 옮기곤 한다.

그런데 메서드가 생성자라면 스텝이 꼬인다. 생성자는 할 수 있는 일과 호출 순서에 제약이 있기 때문에 조금 다른 식으로 접근해야 한다.

절차

• 슈퍼클래스에 생성자가 없다면 하나 정의한다. 서브클래스의 생성자들에서 이 생성자가 호출되는지 확인한다.
• 문장 슬라이드하기로 공통 문장을 모두를 super() 호출 직후로 옮긴다.
• 공통 코드를 슈퍼클래스에 추가하고 서브클래스들에서는 제거한다. 생성자 매개변수 중 공통 코드에서 참조하는 값들을 모두 super()로 건넨다.
• 테스트한다.
• 생성자 시작 부분으로 옮길 수 없는 공통 코드에는 함수 추출하기와 메서드 올리기를 차례로 적용한다.

12.4 메서드 내리기

public class Employee 
{
    public double GetQuota() {...}
}

public class Salesperson : Employee {...}

public class Engineer : Employee {...}

public class Employee {...}

public class Salesperson : Employee {...}

public class Engineer : Employee 
{
    public double GetQuota() {...}
}

배경

특정 서브클래스 하나와만 관련된 메서드는 슈퍼클래스에서 제거하고 해당 서브클래스에 추가하는 편이 깔끔하다.

다만 이 리팩터링은 해당 기능을 제공하는 서브클래스가 정확히 무엇인지를 호출자가 알고 있을 때만 적용할 수 있다.

그렇지 못한 상황이라면 서브클래스에 따라 다르게 동작하는 슈퍼클래스의 기만적인 조건부 로직을 다형성으로 바꿔야 한다.

절차

• 대상 메서드를 모든 서브클래스에 복사한다.
• 슈퍼클래스에서 그 메서드를 제거한다.
• 테스트한다.
• 이 메서드를 사용하지 않는 모든 서브클래스에서 제거한다.
• 테스트한다.

12.5 필드 내리기

public class Employee
{
    private string quota;
}

public class Salesperson : Employee {...}

public class Engineer : Employee {...}

public class Employee {...}

public class Salesperson : Employee 
{
    private string quota;
}

public class Engineer : Employee {...}

배경

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

절차

• 대상 필드를 모든 서브클래스에 정의한다.
• 슈퍼클래스에서 그 필드를 제거한다.
• 테스트한다.
• 이 필드를 사용하지 않는 모든 서브클래스에서 제거한다.
• 테스트한다.

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

public Employee CreateEmployee(string name, Type type)
{
    return new Employee(name, type);
}

public Employee CreateEmployee(string name, Type type)
{
    switch (type)
    {
        case Type.Engineer:
            return new Engineer(name);
        case Type.Salesperson:
            return new Salesperson(name);
        case Type.Manager:
            return new Manager(name);
        default:
            throw new Exception("Incorrect type code value");
    }
}

배경

소프트웨어 시스템에서는 비슷한 대상들을 특정 특성에 따라 구분해야 할 때가 자주 있다.

예컨대 직원을 담당 업무로 구분하거나(엔지니어, 관리자, 영업자 등) 주문을 시급성으로 구분하기도 한다. (급함, 보통 등)

이런 일을 다루는 수단으로는 타입 코드 필드가 있다.

타입 코드는 프로그래밍 언어에 따라 열거형이나 심볼, 문자열, 숫자 등으로 표현하며, 외부 서비스가 제공하는 데이터를 다루려 할 때 딸려오는 일이 흔하다.

타입 코드만으로도 특별히 불편한 사항은 별로 없지만 그 이상의 무언가가 필요할 때가 있다.

여기서 '그 이상'이라 하면 바로 서브클래스를 가리킨다.

서브클래스는 두 가지 면에서 특히 매력적이다.

첫째, 조건에 따라 다르게 동작하도록 해주는 다형성을 제공한다.

타입 코드에 따라 동작이 달라져야 하는 함수가 여러 개일 때 특히 유용하다.

서브클래스를 이용하면 이런 함수들에 조건부 로직을 다형성으로 바꾸기를 적용할 수 있다.

둘째, 특정 타입에서만 의미가 있는 값을 사용하는 필드나 메서드가 있을 때 발현된다.

예컨대 판매 목표는 영업자 유형일 때만 의미가 있다.

이런 상황이라면 서브클래스를 만들고 필요한 서브클래스만 필드를 갖도록 정리하자.

물론 타입 코드를 사용할 때도 타입과 값이 올바르게 짝지어 사용되는지 검증하는 코드를 넣을 수 있지만, 서브 클래스 방식이 관계를 더 명확하게 드러내준다.

절차

• 타입 코드 필드를 자가 캡슐화한다.
• 타입 코드 값 하나를 선택하여 그 값에 해당하는 서브클래스를 만든다. 타입 코드 게터 메서드를 오버라이드하여 해당 타입 코드의 리터럴 값을 반환하게 한다.
• 매개변수로 받은 타입 코드와 방금 만든 서브클래스를 매핑하는 선택로직을 만든다.
• 테스트한다.
• 타입 코드 값 각각에 대해 서브클래스 생성과 선택 로직 추가를 반복한다. 클래스 하나가 완성될 때마다 테스트한다.
• 타입 코드 필드를 제거한다.
• 테스트한다.
• 타입 코드 접근자를 이용하는 메서드 모두 메서드 내리기와 조건부 로직을 다형성으로 바꾸기를 적용한다.

12.7 서브클래스 제거하기

public class Person
{
    public string GetGenderCode()
    {
        return "X";
    }
}

public class Male : Person
{
    public string GetGenderCode()
    {
        return "M";
    }
}

public class Female : Person
{
    public string GetGenderCode()
    {
        return "F";
    }
}

public class Person
{
    public string GetGenderCode()
    {
        return this.genderCode;
    }
}

배경

서브클래싱은 원래 데이터 구조와는 다른 변종을 만들거나 종류에 따라 동작이 달라지게 할 수 있는 유용한 메커니즘이다.

다름을 프로그래밍하는 멋진 수단인 것이다.

하지만 소프트웨어 시스템이 성장함에 따라 서브클래스로 만든 변종이 다른 모듈로 이동하거나 완전히 사라지기도 하면서 가치가 바래기도 한다.

서브클래스는 결국 한 번도 활용되지 않기도 하며, 때론 서브클래스를 필요로 하지 않는 방식으로 만들어진 기능에서만 쓰이기도 한다.

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

이런 정도까지 되면 서브클래스를 슈퍼클래스의 필드로 대체해 제거하는 게 최선이다.

절차

• 서브클래스의 생성자를 팩터리 함수로 바꾼다.
• 서브클래스의 타입을 검사하는 코드가 있다면 그 검사 코드에 함수 추출하기와 함수 옮기기를 차례로 적용하여 슈퍼클래스로 옮긴다. 테스트한다.
• 서브클래스의 타입을 나타내는 필드를 슈퍼클래스에 만든다.
• 서브클래스를 참조하는 메서드가 방금 만든 타입 필드를 이용하도록 수정한다.
• 서브클래스를 지운다.
• 테스트한다.

이 리팩터링은 다수의 서브클래스에 한꺼번에 적용할 때가 많다.

그럴 때는 팩터리 함수를 추가하고 타입 검사 코드를 옮기는 캡슐화 단계들을 먼저 실행한 다음 개별 서브클래스를 하나씩 슈퍼클래스로 흡수시킨다.

12.8 슈퍼클래스 추출하기

public class Department
{
    public string GetTotalAnnualCost() {...}
    public string GetName() {...}
    public string GetHeadCount() {...}
}

public class Employee
{
    public string GetAnnualCost() {...}
    public string GetName() {...}
    public string GetId() {...}
}

public class Party
{
    public string GetName() {...}
}

public class Department : Party
{
    public string GetTotalAnnualCost() {...}
    public string GetHeadCount() {...}
}

public class Employee : Party
{
    public string GetAnnualCost() {...}
    public string GetId() {...}
}

배경

비슷한 일을 수행하는 두 클래스가 보이면 상속 메커니즘을 이용해서 비슷한 부분을 공통의 슈퍼클래스로 옮겨 담을 수 있다.

공통된 부분이 데이터라면 필드 올리기를 활용하고, 동작이라면 메서드 올리기를 활용한다.

객체 지향을 설명할 때 상속 구조는 '현실 세계에서 활용하는 어떤 분류 체계에 기초하여 구현에 들어가기 앞서 부모/자식 관계를 신중하게 설계해야 한다'라고 이야기하는 사람이 많다.

현실 세계의 이런 분류 체계는 상속을 적용하는 데 힌트가 될 수 있다.

절차

• 빈 슈퍼클래스를 만든다. 원래의 클래스들이 새 클래스를 상속하도록 한다.
• 테스트한다.
• 생성자 본문 올리기, 메서드 올리기, 필드 올리기를 차례로 적용하여 공통 원소를 슈퍼클래스로 옮긴다.
• 서브클래스에 남은 메서드들을 검토한다. 공통되는 부분이 있다면 함수로 추출한 다음 메서드 올리기를 적용한다.
• 원래 클래스들을 사용하는 코드를 검토하여 슈퍼클래스의 인터페이스를 사용하게 할지 고민해본다.

12.9 계층 합치기

public class Employee {...}

public class Salesperson : Employee {...}

public class Employee {...}

배경

클래스 계층구조를 리팩터링하다 보면 기능들을 위로 올리거나 아래로 내리는 일은 다반사로 벌어진다.

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

바로 그 둘을 하나로 합쳐야 할 시점이다.

절차

• 두 클래스 중 제거할 것을 고른다.
• 필드 올리기와 메서드 올리기 혹은 필드 내리기와 메서드 내리기를 적용하여 모든 요소를 하나의 클래스로 옮긴다.
• 제거할 클래스를 참조하던 모든 코드가 남겨질 클래스를 참조하도록 고친다.
• 빈 클래스를 제거한다.
• 테스트한다.

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

public class Order
{
    public int GetDaysToShip() 
    {
        return this.warehouse.GetDaysToShip();
    }
}

public class PriorityOrder : Order
{
    public int GetDaysToShip() 
    {
        return this.priorityPlan.GetDaysToShip();
    }
}

public class Order
{
    public int GetDaysToShip() 
    {
        return (this.priorityDelegate) ? this.priorityPlan.GetDaysToShip() : this.warehouse.GetDaysToShip();
    }
}

public class PriorityOrderDelegate
{
    public int GetDaysToShip() 
    {
        return this.priorityPlan.GetDaysToShip();
    }
}

배경

속한 갈래에 따라 동작이 달라지는 객체들은 상속으로 표현하는 게 자연스럽다.

공통 데이터와 동작은 모두 슈퍼클래스에 두고 서브클래스는 자신에 맞게 기능을 추가하거나 오버라이드하면 된다.

객체 지향 언어로는 이런 형태로 구현하기가 쉽기 때문에 흔히 활용되는 메커니즘이다.

하지만 상속에는 단점이 있다.

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

무언가가 달라져야 하는 이유가 여러 개여도 상속에서는 그중 단 하나의 이유만 선택해 기준으로 삼을 수밖에 없다.

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

둘 다는 안 된다.

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

부모를 수정하면 이미 존재하는 자식들의 기능을 해치기가 쉽기 때문에 각별히 주의해야 한다.

그래서 자식들이 슈퍼클래스를 어떻게 상속해 쓰는지를 이해해야 한다.

부모와 자식이 서로 다른 모듈에 속하거나 다른 팀에서 구현한다면 문제가 더 커진다.

위임은 이상의 두 문제를 모두 해결해준다. (여기서 위임은 아마 구성, 합성을 말하는 듯 하다.)

다양한 클래스에 서로 다른 이유로 위임할 수 있다.

위임은 객체 사이의 일반적인 관계이므로 상호작용에 필요한 인터페이스를 명확히 정의할 수 있다.

즉, 상속보다 결합도가 훨씬 약하다.

그래서 서브클래싱 관련 문제에 직면하게 되면 흔히 서브클래스를 위임으로 바꾸곤 한다.

유명한 원칙으로 상속보다는 컴포지션을 사용하라

이를 상속은 위험하다고 받아들여지기도 하는데 이는 과장된 말이다.

상속을 이해 해야지만 구성(위임)의 이점을 이해할 수 있고 상속도 활용할줄 알아야 한다.

절차

• 생성자를 호출하는 곳이 많다면 생성자를 팩터리 함수로 바꾼다.
• 위임으로 활용할 빈 클래스를 만든다. 이 클래스의 생성자는 서브클래스에 특화된 데이터를 전부 받아야 하며, 보통은 슈퍼클래스를 가리키는 역참조도 필요하다.
• 위임을 저장할 필드를 슈퍼클래스에 추가한다.
• 서브클래스 생성 코드를 수정하여 위임 인스턴스를 생성하고 위임 필드에 대입해 초기화한다.
• 서브클래스의 메서드 중 위임 클래스로 이동할 것을 고른다.
• 함수 옮기기를 적용해 위임 클래스로 옮긴다. 원래 메서드에서 위임하는 코드는 지우지 않는다.
• 서브클래스 외부에도 원래 메서드를 호출하는 코드가 있다면 서브클래스의 위임 코드를 슈퍼클래스로 옮긴다. 이때 위임이 존재하는지를 검사하는 보호 코드로 감싸야 한다. 호출하는 외부 코드가 없다면 원래 메서드는 죽은 코드가 되므로 제거한다.
• 테스트한다.
• 서브클래스의 모든 메서드가 옮겨질 때까지 과정을 반복한다.
• 서브클래스들의 생성자를 호출하는 코드를 찾아서 슈퍼클래스의 생성자를 사용하도록 수정한다.
• 테스트한다.
• 서브클래스를 삭제한다.

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

public class List {...}
public class Stack : List {...}

public class Stack
{
    public Stack()
    {
        this.storage = new List();
    }
}

class List {...}

배경

객체 지향 프로그래밍에서 상속은 기존 기능을 재활용하는 강력하고 손쉬운 수단이다.

기존 클래스를 상속하여 입맛에 맞게 오버라이드하거나 새 기능을 추가하면 된다.

하지만 상속이 혼란과 복잡도를 키우는 방식으로 이뤄지기도 한다.

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

자바의 스택은 리스트를 상속하고 있는데, 데이터를 저장하고 조작하는 리스트의 기능을 재활용하겠다는 생각이 초래한 결과다.

재활용이란 관점에서는 좋았지만 이 상속에는 문제가 있다.

자바의 스택은 슈퍼클래스를 위임으로 바꾸는 이번 리팩터링을 적용해야 하는 좋은 예다.

슈퍼클래스의 기능들이 서브클래스에는 어울리지 않는다면 그 기능들을 상속을 통해 이용하면 안된다는 신호다.

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

다시 말해, 슈퍼클래스가 사용되는 모든 곳에서 서브클래스의 인스턴스를 대신 사용해도 이상없이 동작해야 한다.

예컨대 이름과 엔진 크기 등을 속성으로 갖는 자동차 모델 클래스가 있다고 하자.

그러면 여기에 차량 식별 번호와 제조일자 메서드를 더하면 물리적인 자동차를 표현하는 데 재활용할 수 있을 거라 착각할 수 있다.

이는 흔하고 미묘한 모델링 실수로, 내가 타입-인스턴스 동형이의어라고 부르는 것이다.

이상은 모두 혼란과 오류를 일으키는 예인 동시에 상속을 버리고 위임으로 갈아타 객체를 분리하면 쉽게 피할 수 있는 예다.

위임을 이용하면 기능 일부만 빌려올 뿐인, 서로 별개인 개념임이 명확해진다.

서브클래스 방식 모델링이 합리적일 때라도 슈퍼클래스를 위임으로 바꾸기도 한다.

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

위임에도 물론 단점이 존재한다.

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

전달 함수를 작성하기란 지루한 일이다. 하지만 아주 단순해서 문제가 생길 가능성은 적다.

이상의 이유로 "상속은 절대 사용하지 말라"고 조언하는 사람도 있지만, 실상은 그렇지 않다. (반대한다.)

상위 타입의 모든 메서드가 하위 타입에도 적용되고, 하위 타입의 모든 인스턴스가 상위 타입의 인스턴스도 되는 등, 의미상 적합한 조건이라면 상속은 간단하고 효과적인 메커니즘이다.

생각

개인적인 생각이지만 그렇다고 3계층 이상으로 깊어지는 상속은 좋게 볼 수 없는 것 같다.

1~2 깊이 정도는 읽는 사람이 이해하는데 문제가 없지만 그 이상 깊어진다면 너무 단단한, 수정할 수 없는 비석느낌이 강하다.

절차

• 슈퍼클래스 객체를 참조하는 필드를 서브클래스에 만든다. 위임 참조를 새로운 슈퍼클래스 인스턴스로 초기화한다.
• 슈퍼클래스의 동작에 각각 대응하는 전달 함수를 서브클래스에 만든다.(위임 참조로 전달) 서로 관련된 함수끼리 그룹으로 묶어서 진행하며, 그룹을 하나씩 만들 때마다 테스트한다.
• 슈퍼클래스의 동작 모두가 전달 함수로 오버라이드되었다면 상속 관계를 끊는다.

느낀점

마지막 장이 상속, 객체지향에 관련된 내용이라 매우 도움이 된 것 같다.

중간 중간 클린코드의 내용이 나와 반갑기도 했고, 최근에 읽은 객체지향 사고 프로세스에서 하고 싶었던 말도 있어서 개인적인 생각을 정리했다.

논의사항

• 이번 장에선 위임, 서브클래스, 슈퍼클래스에 경계에 대한 내용이 주를 이뤘는데 실제로 위에서 말한 리팩터링을 진행해보신 적이 있나요?