10 CHAPTER 상속과 코드 재사용

https://wikibook.co.kr/object/

오브젝트: 코드로 이해하는 객체지향 설계

 

 

객체지향에서는 코드를 재사용하기 위해 ‘새로운’코드를 추가한다.

객체지향에서 코드는 일반적으로 클래스 안에 작성되기 때문에 객체지향에서 클래스를 재사용하는 전통적인 방법은 새로운 클래스를 추가하는 것이다.

재사용 관점에서 상속이란 클래스 안에 정의된 인스턴스 변수와 메서드를 자동으로 새로운 클래스에 추가하는 구현 기법이다.

◈ 상속과 중복 코드

Dry 원칙

중복코드는 변경을 방해한다.

이것이 중복 코드를 제거해야 하는 가장 큰 이유다.

 

중복 코드가 가지는 가장 큰 문제는 코드를 수정하는 데 필요한 노력을 몇 배로 증가시킨다는 것이다.

 

중복 여부를 판단하는 기준은 변경이다.

요구사항이 변경됐을 때 두 코드를 함께 수정해야 한다면 이 코드는 중복이다.

모양이 유사하다는 것은 단지 중복의 징후일 뿐이다.

중복 여부를 결정하는 기준은 코드가 변경에 반응하는 방식이다.

 

중복과 변경

중복 코드는 새로운 중복 코드를 부른다.

중복 코드를 제거하지 않은 상태에서 코드를 수정할 수 있는 유일한 방법은 새로운 중복 코드를 추가하는 것뿐이다.

새로운 중복 코드를 추가하는 과정에서 코드의 일관성이 무너질 위험이 항상 도사리고 있다.

더 큰 문제는 중복 코드가 늘어날수록 애플리케이션은 변경에 취약해지고 버그가 발생할 가능성이 높아진다는 것이다.

중복 코드의 양이 많아질수록 버그의 수는 증가하며 그에 비례해 코드를 변경하는 속도는 점점 느려진다.

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

상속을 염두에 두고 설계되지 않은 클래스를 상속을 이용해 재사용하는 것은 생각처럼 쉽지 않다.

개발자는 재사용을 위해 상속 계층 사이에 무수히 많은 가정을 세웠을지도 모른다.

그리고 그 가정은 코드를 이해하기 어렵게 만들뿐만 아니라 직관에도 어긋날 수 있다.

 

상속을 이용해 코드를 재사용하기 위해서는 부모 클래스의 개발자가 세웠던 가정이나 추론 과정을 정확하게 이해해야 한다.

이것은 자식 클래스의 작성자가 부모 클래스 구현 방법에 대한 정확한 지식을 가져야 한다는 것을 의미한다.

 

따라서 상속은 결합도를 높인다.

그리고 상속이 초래하는 부모 클래스와 자식 클래스 사이의 강한 결합이 코드를 수정하기 어렵게 만든다.

강하게 결합된 상속된 코드

강하게 결합하는 상속을 사용하게 되면 코드 중복을 제거하기 위해 상속을 사용했음에도 로직을 추가하기 위해 새로운 중복 코드를 만들어야 한다.

 

상속을 위한 경고 1.

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

 

 

자식 클래스가 부모 클래스의 구현에 강하게 결합될 경우 부모 클래스의 변경에 의해 자식 클래스가 영향을 받는다.

상속을 사용하면 적은 노력으로도 새로운 기능을 쉽고, 빠르게 추가할 수 있다.

하지만 그로 인해 커다란 대가를 치러야 할 수도 있다.

 

이처럼 상속 관계로 연결된 자식 클래스가 부모 클래스의 변경에 취약해지는 현상을 가리켜 취약한 기반 클래스 문제라고 부른다.

◈ 취약한 기반 클래스 문제

취약한 기반 클래스 문제는 상속을 사용한다면 피할 수 없는 객체지향 프로그래밍의 근본적인 취약성이다.

 

상속 관계를 추가할수록 전체 시스템의 결합도가 높아진다는 사실을 알고 있어야 한다.

 

객체를 사용하는 이유는 구현과 관련된 세부사항을 퍼블릭 인터페이스 뒤로 캡슐화할 수 있기 때문이다.

캡슐화는 변경에 의한 파급효과를 제어할 수 있기 때문에 가치가 있다.

 

안타깝게도 상속을 사용하면 부모 클래스의 퍼블릭 인터페이스가 아닌 구현을 변경하더라도 자식 클래스가 영향을 받기 쉬워진다.

 

객체지향의 기반은 캡슐화를 통한 변경의 통제다.

상속은 코드의 재사용을 위해 캡슐화의 장점을 희석시키고 구현에 대한 결합도를 높임으로써 객체지향이 가진 강력함을 반감시킨다.

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

인터페이스 설계는 제대로 쓰기엔 쉽게, 엉터리로 쓰기엔 어렵게 만들어야 한다.

 

객체지향의 핵심은 객체들의 협력이다.

단순히 코드를 재사용하기 위해 불필요한 오퍼레이션이 인터페이스에 스며들도록 방치해서는 안 된다.

 

상속을 위한 경고 2.

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

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

상속을 위한 경고 3.

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

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

상속을 위한 경고 4.

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

◈ 상속으로 인한 피해 최소화하기.

추상화에 의존하자.

상속으로 인한 문제를 해결하는 가장 일반적인 방법은 자식 클래스가 부모 클래스의 구현이 아닌 추상화에 의존하도록 만드는 것이다.

정확하게 말하면 부모 클래스와 자식 클래스 모두 추상화에 의존하도록 수정해야 한다.

코드 중복을 제거하기 위해 상속을 도입할 때 따르는 두 가지 원칙.

1. 두 메서드가 유사하게 보인다면 차이점을 메서드로 추출하라.

메서드 추출을 통해 두 메서드를 동일한 형태로 보이도록 만들 수 있다.

 

2. 부모 클래스의 코드를 하위로 내리지 말고 자식 클래스의 코드를 상위로 올려라.

부모 클래스의 구체적인 메서드를 자식 클래스로 내리는 것보다 자식 클래스의 추상적인 메서드를 부모 클래스로 올리는 것이 재사용성과 응집도 측면에서 더 뛰어난 결과를 얻을 수 있다.

차이를 메서드로 추출하라.

가장 먼저 할 일은 중복 코드 안에서 차이점을 별도의 메서드로 추출하는 것이다.

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

공통 코드를 옮길 때 인스턴스 변수보다 메서드를 먼저 이동시키는 게 편한데, 메서드를 옮기고 나면 그 메서드에 필요한 메서드나 인스턴스 변수가 무엇인지를 컴파일 에러를 통해 자동으로 알 수 있기 때문이다.

컴파일 에러를 바탕으로 메서드와 인스턴스 변수를 이동시키면 불필요한 부분은 자식 클래스에 둔 채로 부모 클래스에 꼭 필요한 코드만 이용시킬 수 있다.

 

자식 클래스들 사이의 공통점을 부모 클래스로 옮김으로써 실제 코드를 기반으로 상속 계층을 구성할 수 있다.

추상화가 핵심이다.

자식 클래스는 부모 클래스의 구체적인 구현에 의존하지 않는다.

오직 추상화에만 의존한다.

정확하게는 부모 클래스에서 정의한 추상메서드에만 의존한다.

이 추상 메서드의 시그니처가 변경되지 않는한 부모 클래스의 내부 구현이 변경되더라도 자식 클래스는 영향을 받지 않는다.

 

부모 클래스 역시 자신의 내부에 구현된 추상 메서드를 호출하기 때문에 추상화에 의존한다고 말할 수 있다.

 

상속 계층이 코드를 진화시키는 데 걸림돌이 된다면 추상화를 찾아내고 상속 계층 안의 클래스들이 그 추상화에 의존하도록 코드를 리팩터링하라.

차이점을 메서드로 추출하고 공통적인 부분은 부모 클래스로 이동하라.

코드 변경하기.

클래스라는 도구는 메서드뿐만 아니라 인스턴스 변수도 함께 포함한다.

따라서 클래스 사이의 상속은 자식 클래스가 부모 클래스가 구현한 행동뿐만 아니라 인스턴스 변수에 대해서도 결합되게 만든다.

 

자식 클래스는 자신의 인스턴스를 생성할 때 부모 클래스에 정의된 인스턴스 변수를 초기화해야 하기 때문에 자연스럽게 부모 클래스에 추가된 인스턴스 변수는 자식 클래스의 초기화 로직에 영향을 미치게 된다.

결과적으로 책임을 아무리 잘 분리하더라도 인스턴스 변수의 추가는 종종 상속 계층 전반에 걸친 변경을 유발한다.

 

객체 생성 로직의 변경에 유연하게 대응할 수 있는 다양한 방법이 존재한다.

따라서 객체 생성 로직에 대한 변경을 막기보다는 핵심 로직의 중복을 막아라.

핵심 로직은 한 곳에 모아 놓고 조심스럽게 캡슐화해야 한다.

그리고 공통적인 핵심 로직은 최대한 추상화해야 한다.

 

상속은 어떤 방식으로든 부모 클래스와 자식 클래스를 결합시킨다.

메서드 구현에 대한 결합은 추상 메서드를 추가함으로써 어느 정도 완화할 수 있지만 인스턴스 변수에 대한 잠재적인 결합을 제거할 수 있는 방법은 없다.