오브젝트 독서회 9회차 - 10장 상속과 코드 재사용

독서회를 처음 구성할 때 인원들이 강남에서 모일 때 가장 절충안이었기 때문에 강남에서 주로 스터디를 했지만, 요즘 출석률이 좋은 @vincent @freebear @콘크리트장인 님들과 장소를 다시 절충하여 사당역 부근으로 장소를 이동해봤습니다.

홈 | 스터디룸 위드 사당점 (modoo.at)

위에서 진행했는데, 확실히 강남에 있는 스터디룸들 보다 시설도 좋고, 가격도 저렴했습니다. 처음 간 날은 방음이 안되서 옆방때문에 좀 시끄러웠지만 굳이 스터디 목적이 아니더라도 저렴한 가격으로, 조용한 곳에서 진지한 대화를 나눌 목적으로 사용해도 좋을 것 같습니다.

10장은 양이 좀 적었고, 읽을만 했던 것으로 기억납니다. 11월 8일에 진행했었네요.


P308

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

@콘크리트장인

P309

중복 코드는 사람들의 마음속에 의심과 불신의 씨앗을 뿌린다.

@freebear

중복 코드는 우리를 주저하게 만들뿐만 아니라 동료들을 의심하게 만든다.

@vincent

중복 코드는 변경을 방해한다. 이것이 중복 코드를 제거해야 하는 가장 큰 이유다. 프로그램의 본질은 비즈니스와 관련된 지식을 코드로 변환하는 것이다. 안타깝게도 이 지식은 항상 변한다. 그에 맞춰 지식을 표현하는 코드 역시 변경해야 한다. 그 이유가 무엇이건 일단 새로운 코드를 추가하고 나면 언젠가는 변경될 것이라고 생각하는 것이 현명하다.

@vincent @freebear @콘크리트장인

중복 코드가 가지는 가장 큰 문제는 코드를 수정하는데 필요한 노력을 몇 배로 증가시킨다는 것이다. 우선 어떤 코드가 중복인지를 찾아야 한다. 일단 중복 코드의 묶음을 찾았다면 찾아낸 모든 코드를 일관되게 수정해야 한다.

@콘크리트장인

중복 여부를 판단하는 기준은 변경이다. 요구사항이 변경됐을 때 두 코드를 함께 수정해야 한다면 이 코드는 중복이다.

@freebear @콘크리트장인

중복 코드를 결정하는 기준은 코드의 모양이 아니다.

@freebear

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

@freebear @콘크리트장인

DRY 는 '반복하지 마라’라는 뜻의 Don’t Repeat Yourself 의 첫 글자를 모아 만든 용어로 간단히 말해 동일한 지식을 중복하지 말라는 것이다.

@vincent @freebear @콘크리트장인

P310

원칙의 이름이 무엇이건 핵심은 코드 안에 중복이 존재해서는 안 된다는 것이다.

@freebear

P312

요구사항은 항상 변한다.

@콘크리트장인

P315

많은 코드 더미 속에서 어떤 코드가 중복인지를 파악하는 일은 쉬운 일이 아니다. 중복 코드는 항상 함께 수정돼야 하기 때문에 수정할 때 하나라도 빠트린다면 버그로 이어질 것이다.

@콘크리트장인

P316

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

@콘크리트장인

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

@freebear

민첩하게 변경하기 위해서는 중복 코드를 추가하는 대신 제거해야 한다. 기회가 생길 때마다 코드를 DRY하게 만들기 위해 노력하라.

@freebear

두 클래스 사이의 중복 코드를 제거하는 한 가지 방법은 클래스를 하나로 합치는 것이다.

@콘크리트장인

하지만 계속 강조했던 것처럼 타입 코드를 사용하는 클래스는 낮은 응집도와 높은 결합도라는 문제에 시달리게 된다.

@콘크리트장인

P317

객체지향 프로그래밍 언어는 타입 코드를 사용하지 않고도 중복 코드를 관리할 수 있는 효과적인 방법을 제공한다. 이 방법은 너무나 유명해서 객체지향 프로그래밍을 대표하는 기법으로 일컬어지기도 한다. 상속이 바로 그것이다.

@freebear @콘크리트장인

P318

상속의 기본 아이디어는 매우 간단하다. 이미 존재하는 클래스와 유사한 클래스가 필요하다면 코드를 복사하지 말고 상속을 이용해 코드를 재사용하라는 것이다.

@vincent @콘크리트장인

P320

중요한 것은 개발자의 가정을 이해하기 전에는 코드를 이해하기 어렵다는 점이다.

@vincent

잘못 사용된 상속은 이 차이를 더 크게 벌린다.

@vincent

실제 프로젝트에서 마주치게 될 코드는 여기서 설명한 예보다 훨씬 더 엉망일 확률이 높다. 여기서는 단지 두 클래스 사이의 상속 관계만 살펴봤지만 실제 프로젝트에서 마주치게 될 클래스의 상속 계층은 매우 깊을 것이다.

@콘크리트장인

이 예제에서 볼 수 있는 것처럼 상속을 이용해 코드를 재사용하기 위해서는 부모 클래스의 개발자가 세웠던 가정이나 추론 과정을 정확하게 이해해야 한다. 이것은 자식 클래스의 작성자가 부모 클래스의 구현 방법에 대한 정확한 지식을 가져야 한다는 것을 의미한다.

@콘크리트장인

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

@콘크리트장인

P322

지금까지 살펴본 예제들은 자식 클래스가 부모 클래스의 구현에 강하게 결합될 경우 부모 클래스의 변경에 의해 자식 클래스가 영향을 받는다는 사실을 잘 보여준다. 상속을 사용하면 적은 노력으로도 새로운 기능을 쉽고, 빠르게 추가할 수 있다. 하지만 그로 인해 커다란 대가를 치러야 할 수도 있다.

@freebear

P323

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

@vincent @freebear @콘크리트장인

P326

Stack과 Properties의 예는 퍼블릭 인터페이스에 대한 고려 없이 단순히 코드 재사용을 위해 상속을 이용하는 것이 얼마나 위험한지를 잘 보여준다.

@freebear

P329

더 일반적으로 말하면 오버라이딩 가능한 메서드를 호출할 수 있는 어떤 상황에 대해서도 문서화해야 한다는 것이다[Bloch08].

@콘크리트장인

이것은 결국 상속이 캡슐화를 위반함으로써 초래된 불행인 것이다.

@콘크리트장인

설계는 트레이드오프 활동이라는 사실을 기억하라. 상속은 코드 재사용을 위해 캡슐화를 희생한다. 완벽한 캡슐화를 원한다면 코드 재사용을 포기하거나 상속 이외의 다른 방법을 사용해야 한다.

@vincent @freebear @콘크리트장인

P331

이 예는 자식 클래스가 부모 클래스의 메서드를 오버라이딩하거나 불필요한 인터페잉스를 상속받지 않았음에도 부모 클래스를 수정할 때 자식 클래스를 함꼐 수정해야 할 수도 있다는 사실을 잘 보여준다.

@콘크리트장인

결합도란 다른 대상에 대해 알고 있는 지식의 양이다. 상속은 기본적으로 부모 클래스의 구현을 재사용한다는 기본 전제를 따르기 때문에 자식 클래스가 부모 클래스의 내부에 대해 속속들이 알도록 강요한다.

@vincent

P332

이 문제를 해결하는 가장 일반적인 방법은 자식 클래스가 부모 클래스의 구현이 아닌 추상화에 의존하도록 만드는 것이다. 정확하게 말하면 부모 클래스와 지식 클래스 모두 추상화에 의존하도록 수정해야 한다.

@vincent @freebear @콘크리트장인

P333

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

@vincent @freebear @콘크리트장인

P336

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

@freebear

이제 Phone과 NightDiscountPhone의 공통 부분을 부모 클래스로 이동시키자.

@콘크리트장인

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

@vincent

P339

추상화하지 않고 빼먹은 코드가 있더라도 하위 클래스가 해당 행동을 필요로 할 때가 오면 이 문제는 바로 눈에 띈다.

@콘크리트장인

위로 올리기에서 실수하더라도 추상화할 코드는 눈에 띄고 결국 상위 클래스로 올려지면서 코드의 품질이 높아진다.

@콘크리트장인

P340

추상화가 핵심이다

@콘크리트장인

P343

자식 클래스는 자신의 인스턴스를 생성할 때 부모 클래스에 정의된 인스턴스 변수를 초기화해야 하기 때문에 자연스럽게 부모 클래스에 추가된 인스턴스 변수는 자식 클래스의 초기화 로직에 영향을 미치게 된다. 결과적으로 책임을 아무리 잘 분리하더라도 인스턴스 변수의 추가는 종종 상속 계층 전반에 걸친 변경을 유발한다.

@콘크리트장인

하지만 인스턴스 초기화 로직을 변경하는 것이 두 클래스에 동일한 세금 계산 코드를 중복시키는 것보다는 현명한 선택이다.

@콘크리트장인

객체 생성 로직의 변경에 유연하게 대응할 수 있는 다양한 방법이 존재한다. 따라서 객체 생성 로직에 대한 변경을 막기보다는 핵심 로직의 중복을 막아라. 핵심 로직은 한 곳에 모아 놓고 조심스럽게 캡슐화해야 한다. 그리고 공통적인 핵심 로직은 최대한 추상화해야 한다.

@freebear

지금까지 살펴본 것처럼 상속으로 인한 클래스 사이의 결합을 피할 수 있는 방법은 없다. 상속은 어떤 방식으로든 부모 클래스와 자식 클래스를 결합시킨다.

@vincent

P344

상속이 강력한 이유는 익숙한 개념을 이용해서 새로운 개념을 쉽고 빠르게 추가할 수 있기 때문이다.

@vincent

이처럼 기존 코드와 다른 부분만을 추가함으로써 애플리케이션의 기능을 확장하는 방법을 차이에 의한 프로그래밍(programming by difference) [Feathers 2004]이라고 부른다.

@vincent @콘크리트장인

프로그래밍의 세계에서 중복 코드는 악의 근원이다. 따라서 중복 코드를 제거하기 위해 최대한 코드를 재사용해야 한다.

@vincent @콘크리트장인

P345

상속은 강력한 도구다.

@vincent

시간이 흐르고 객체지향에 대한 이해가 깊어지면서 사람들은 코드를 재사용하기 위해 맹목적으로 상속을 사용하는 것이 위험하다는 사실을 깨닫기 시작했다.

@콘크리트장인

상속은 코드 재사용과 관련된 대부분의 경우에 우아한 해결 방법이 아니다.

@vincent

7 Likes

이번 장부터는 상속이 등장합니다.

제 기억으로는 대학생 때 Java로 객체지향 프로그래밍을 배웠을 때 그 책의 커리큘럼이 Class를 먼저 배우고, 상속을 배운 다음 Interface를 배우고 그 다음 일반화 프로그래밍을 배웠던 것으로 기억이 나는데, 확실히 이 책은 문법책이 아니어서 그런지 OOP의 개념 중 중요한 부분부터 먼저 설명을 해주는 것 같습니다.

저도 얼마전까지 그랬듯, 누가 추상클래스와 인터페이스의 차이를 물어보면, 추상클래스에는 virtual method로 기본구현을 사용할 수 있기 때문에 기본 구현이 필요하면 추상클래스, 그게 아니라면 인터페이스를 쓰라고 안내했었습니다.

그런데 이 책을 보면 위 말은 틀린 말입니다. 물론 언어의 형태가 class에서 가상 메서드를 정의한 뒤 상속하므로 메서드를 재활용하는 것을 허용하고 있기에 코드적으로 중복소스코드를 줄일 수 있는 것임에는 분명합니다. 그리고 또 많은 사람들이 중복소스코드를 제거하는 목적으로 사용할 것 같습니다. 저도 그랬구요.

하지만 중복소스코드를 방지하는 것은 다른 위험을 낳습니다. 역시 이것도 트레이드오프라고 볼 수 있겠네요. 하나의 클래스에서 기능을 관리하면 파생 클래스에서 재사용이 쉽지만 그 기반이 되는 슈퍼 클래스의 기능이 틀렸다면, 혹은 파생 클래스에게 적합하지 않는 기능이었다면 슈퍼클래스던, 파생클래스던 둘 다 기능에 의해서 변경이 발생합니다.

중복 소스코드를 제거하기 위해 상속을 사용했지만 오히려 변경에 취향해진 상태라는 것입니다. 지식수준의 차이에 따라서, 누군가는 “그건 소스코드 중복을 방지하기 위해서 일원화 한 거니까 당연한거 아니야?” 라고 할 수는 있겠습니다. 하지만 OOP는 변경에 유연한 코드를 만드는 기법이고 위와 같은 마음을 먹은 개발자가 있다면 지식수준의 차이가 발생할 것입니다.

중복 소스코드를 제거하는 것은 옳습니다. 다만, 위와 같이 되지 않으려면 한 가지 명심해야 할 것은, 그 기본 기능을 가지고 있는 슈퍼클래스가 다중 Layer로 되어 있어야 한다는 것입니다. 물론 필요 없다면 안 해도 되겠지만, 중복 소스코드를 줄이기 위해서 클래스들을 묶어서 슈퍼 클래스를 ‘일부러’ 만들었다면, 분명 슈퍼클래스는 1~2개 일 것입니다. 말그대로 중복 소스코드를 제거한 목표를 달성했으니까 거기서 끝난 것입니다.

하지만 로직이 중복되었을 때 사이드 이펙트를 고려한다면, 단일계층이나, 적은 계층이 아니라 많은 레이어로 나누는 것이 먼저 선행되어야 하는데 그것을 해주는 것이 다중 구현이 가능한 인터페이스 구현인 것 같습니다. 소프트웨어가 도메인 모델을 표현하기 위해 있다고 해도, 소프트웨어는 현실세계와 동일한 비즈니스 구조를 갖는 것이 아니라 추상화 원칙들에 의거해서 개발했을 때 그 표현이 비즈니스로 나타나는 것입니다.

객체와 객체 간의 책임으로 서로 응집도를 높인다는 것은, 비즈니스가 비즈니스로 연결되는, 객체가 특정 객체에 의존하는 그런 것이 아니라, 비즈니스와는 무관한 실제 객체의 책임과 책임이 연결되었을 때 그 워크플로우가 끝나고 결과를 확인했더니 비즈니스를 처리한 것이더라. 라고 되는 게 맞다는 생각이 들었습니다.

4 Likes