독서회를 처음 구성할 때 인원들이 강남에서 모일 때 가장 절충안이었기 때문에 강남에서 주로 스터디를 했지만, 요즘 출석률이 좋은 @vincent @freebear @은딩 님들과 장소를 다시 절충하여 사당역 부근으로 장소를 이동해봤습니다.
위에서 진행했는데, 확실히 강남에 있는 스터디룸들 보다 시설도 좋고, 가격도 저렴했습니다. 처음 간 날은 방음이 안되서 옆방때문에 좀 시끄러웠지만 굳이 스터디 목적이 아니더라도 저렴한 가격으로, 조용한 곳에서 진지한 대화를 나눌 목적으로 사용해도 좋을 것 같습니다.
10장은 양이 좀 적었고, 읽을만 했던 것으로 기억납니다. 11월 8일에 진행했었네요.
P308
객체지향에서는 코드를 재사용하기 위해 '새로운’코드를 추가한다.
P309
중복 코드는 사람들의 마음속에 의심과 불신의 씨앗을 뿌린다.
중복 코드는 우리를 주저하게 만들뿐만 아니라 동료들을 의심하게 만든다.
중복 코드는 변경을 방해한다. 이것이 중복 코드를 제거해야 하는 가장 큰 이유다. 프로그램의 본질은 비즈니스와 관련된 지식을 코드로 변환하는 것이다. 안타깝게도 이 지식은 항상 변한다. 그에 맞춰 지식을 표현하는 코드 역시 변경해야 한다. 그 이유가 무엇이건 일단 새로운 코드를 추가하고 나면 언젠가는 변경될 것이라고 생각하는 것이 현명하다.
중복 코드가 가지는 가장 큰 문제는 코드를 수정하는데 필요한 노력을 몇 배로 증가시킨다는 것이다. 우선 어떤 코드가 중복인지를 찾아야 한다. 일단 중복 코드의 묶음을 찾았다면 찾아낸 모든 코드를 일관되게 수정해야 한다.
중복 여부를 판단하는 기준은 변경이다. 요구사항이 변경됐을 때 두 코드를 함께 수정해야 한다면 이 코드는 중복이다.
중복 코드를 결정하는 기준은 코드의 모양이 아니다.
중복 여부를 결정하는 기준은 코드가 변경에 반응하는 방식이다.
DRY 는 '반복하지 마라’라는 뜻의 Don’t Repeat Yourself 의 첫 글자를 모아 만든 용어로 간단히 말해 동일한 지식을 중복하지 말라는 것이다.
P310
원칙의 이름이 무엇이건 핵심은 코드 안에 중복이 존재해서는 안 된다는 것이다.
P312
요구사항은 항상 변한다.
P315
많은 코드 더미 속에서 어떤 코드가 중복인지를 파악하는 일은 쉬운 일이 아니다. 중복 코드는 항상 함께 수정돼야 하기 때문에 수정할 때 하나라도 빠트린다면 버그로 이어질 것이다.
P316
지금 살펴본 것처럼 중복 코드는 새로운 중복 코드를 부른다. 중복 코드를 제거하지 않은 상태에서 코드를 수정할 수 있는 유일한 방법은 새로운 중복 코드를 추가하는 것뿐이다.
중복 코드의 양이 많아질수록 버그의 수는 증가하며 그에 비례해 코드를 변경하는 속도는 점점 더 느려진다.
민첩하게 변경하기 위해서는 중복 코드를 추가하는 대신 제거해야 한다. 기회가 생길 때마다 코드를 DRY하게 만들기 위해 노력하라.
두 클래스 사이의 중복 코드를 제거하는 한 가지 방법은 클래스를 하나로 합치는 것이다.
하지만 계속 강조했던 것처럼 타입 코드를 사용하는 클래스는 낮은 응집도와 높은 결합도라는 문제에 시달리게 된다.
P317
객체지향 프로그래밍 언어는 타입 코드를 사용하지 않고도 중복 코드를 관리할 수 있는 효과적인 방법을 제공한다. 이 방법은 너무나 유명해서 객체지향 프로그래밍을 대표하는 기법으로 일컬어지기도 한다. 상속이 바로 그것이다.
P318
상속의 기본 아이디어는 매우 간단하다. 이미 존재하는 클래스와 유사한 클래스가 필요하다면 코드를 복사하지 말고 상속을 이용해 코드를 재사용하라는 것이다.
P320
중요한 것은 개발자의 가정을 이해하기 전에는 코드를 이해하기 어렵다는 점이다.
잘못 사용된 상속은 이 차이를 더 크게 벌린다.
실제 프로젝트에서 마주치게 될 코드는 여기서 설명한 예보다 훨씬 더 엉망일 확률이 높다. 여기서는 단지 두 클래스 사이의 상속 관계만 살펴봤지만 실제 프로젝트에서 마주치게 될 클래스의 상속 계층은 매우 깊을 것이다.
이 예제에서 볼 수 있는 것처럼 상속을 이용해 코드를 재사용하기 위해서는 부모 클래스의 개발자가 세웠던 가정이나 추론 과정을 정확하게 이해해야 한다. 이것은 자식 클래스의 작성자가 부모 클래스의 구현 방법에 대한 정확한 지식을 가져야 한다는 것을 의미한다.
따라서 상속은 결합도를 높인다. 그리고 상속이 초래하는 부모 클래스와 자식 클래스 사이의 강한 결합이 코드를 수정하기 어렵게 만든다.
P322
지금까지 살펴본 예제들은 자식 클래스가 부모 클래스의 구현에 강하게 결합될 경우 부모 클래스의 변경에 의해 자식 클래스가 영향을 받는다는 사실을 잘 보여준다. 상속을 사용하면 적은 노력으로도 새로운 기능을 쉽고, 빠르게 추가할 수 있다. 하지만 그로 인해 커다란 대가를 치러야 할 수도 있다.
P323
객체지향의 기반은 캡슐화를 통한 변경의 통제다. 상속은 코드의 재사용을 위해 캡슐화의 장점을 희석시키고 구현에 대한 결합도를 높임으로써 객체지향이 가진 강력함을 반감시킨다.
P326
Stack과 Properties의 예는 퍼블릭 인터페이스에 대한 고려 없이 단순히 코드 재사용을 위해 상속을 이용하는 것이 얼마나 위험한지를 잘 보여준다.
P329
더 일반적으로 말하면 오버라이딩 가능한 메서드를 호출할 수 있는 어떤 상황에 대해서도 문서화해야 한다는 것이다[Bloch08].
이것은 결국 상속이 캡슐화를 위반함으로써 초래된 불행인 것이다.
설계는 트레이드오프 활동이라는 사실을 기억하라. 상속은 코드 재사용을 위해 캡슐화를 희생한다. 완벽한 캡슐화를 원한다면 코드 재사용을 포기하거나 상속 이외의 다른 방법을 사용해야 한다.
P331
이 예는 자식 클래스가 부모 클래스의 메서드를 오버라이딩하거나 불필요한 인터페잉스를 상속받지 않았음에도 부모 클래스를 수정할 때 자식 클래스를 함꼐 수정해야 할 수도 있다는 사실을 잘 보여준다.
결합도란 다른 대상에 대해 알고 있는 지식의 양이다. 상속은 기본적으로 부모 클래스의 구현을 재사용한다는 기본 전제를 따르기 때문에 자식 클래스가 부모 클래스의 내부에 대해 속속들이 알도록 강요한다.
P332
이 문제를 해결하는 가장 일반적인 방법은 자식 클래스가 부모 클래스의 구현이 아닌 추상화에 의존하도록 만드는 것이다. 정확하게 말하면 부모 클래스와 지식 클래스 모두 추상화에 의존하도록 수정해야 한다.
P333
가장 먼저 할 일은 중복 코드 안에서 차이점을 별도의 메서드로 추출하는 것이다. 이것은 흔히 말하는 “변하는 것으로부터 변하지 않는 것을 분리하라.” 또는 "변하는 부분을 찾고 이를 캡슐화하라"라는 조언을 메서드 수준에서 적용한 것이다.
P336
중복 코드를 부모 클래스로 올려라
이제 Phone과 NightDiscountPhone의 공통 부분을 부모 클래스로 이동시키자.
공통 코드를 옮길 때 인스턴스 변수보다 메서드를 먼저 이동시키는 게 편한데, 메서드를 옮기고 나면 그 메서드에 필요한 메서드나 인스턴스 변수가 무엇인지를 컴파일 에러를 통해 자동으로 알 수 있기 떄문이다.
P339
추상화하지 않고 빼먹은 코드가 있더라도 하위 클래스가 해당 행동을 필요로 할 때가 오면 이 문제는 바로 눈에 띈다.
위로 올리기에서 실수하더라도 추상화할 코드는 눈에 띄고 결국 상위 클래스로 올려지면서 코드의 품질이 높아진다.
P340
추상화가 핵심이다
P343
자식 클래스는 자신의 인스턴스를 생성할 때 부모 클래스에 정의된 인스턴스 변수를 초기화해야 하기 때문에 자연스럽게 부모 클래스에 추가된 인스턴스 변수는 자식 클래스의 초기화 로직에 영향을 미치게 된다. 결과적으로 책임을 아무리 잘 분리하더라도 인스턴스 변수의 추가는 종종 상속 계층 전반에 걸친 변경을 유발한다.
하지만 인스턴스 초기화 로직을 변경하는 것이 두 클래스에 동일한 세금 계산 코드를 중복시키는 것보다는 현명한 선택이다.
객체 생성 로직의 변경에 유연하게 대응할 수 있는 다양한 방법이 존재한다. 따라서 객체 생성 로직에 대한 변경을 막기보다는 핵심 로직의 중복을 막아라. 핵심 로직은 한 곳에 모아 놓고 조심스럽게 캡슐화해야 한다. 그리고 공통적인 핵심 로직은 최대한 추상화해야 한다.
지금까지 살펴본 것처럼 상속으로 인한 클래스 사이의 결합을 피할 수 있는 방법은 없다. 상속은 어떤 방식으로든 부모 클래스와 자식 클래스를 결합시킨다.
P344
상속이 강력한 이유는 익숙한 개념을 이용해서 새로운 개념을 쉽고 빠르게 추가할 수 있기 때문이다.
이처럼 기존 코드와 다른 부분만을 추가함으로써 애플리케이션의 기능을 확장하는 방법을 차이에 의한 프로그래밍(programming by difference) [Feathers 2004]이라고 부른다.
프로그래밍의 세계에서 중복 코드는 악의 근원이다. 따라서 중복 코드를 제거하기 위해 최대한 코드를 재사용해야 한다.
P345
상속은 강력한 도구다.
시간이 흐르고 객체지향에 대한 이해가 깊어지면서 사람들은 코드를 재사용하기 위해 맹목적으로 상속을 사용하는 것이 위험하다는 사실을 깨닫기 시작했다.
상속은 코드 재사용과 관련된 대부분의 경우에 우아한 해결 방법이 아니다.