[루비로 배우는 객체지향 디자인] 6장~끝 정리

6장 상속을 이용해 새로운 행동 얻기

6.1 고전적 상속 이해하기 - 자동화된 (이해할 수 없는)메시지 전달 시스템

 

6.2 상속을 사용해야 하는 지점을 알기

구체 클래스에서 시작하기 - 상당수가 이미 만들어져있는 유사품에서 시작하기

자전거 종류 추가하기 - 기존 클래스에 코드 추가 x 부품 이름에 의존하는 메서드 x 의존성을 주의하자

숨겨진 타입 찾아내기 - 같은 행동을 공유하지만 특정 관점(숨겨진 타입)에서 다른 경우에 상속을 통해 해결한다.

상속을 선택하기 - 하나의 부모클래스만 선택한다. 상위클래스는 하나 이상의 하위 클래스를 가질 수 있지만 하위 클래스는 하나의 상위클래스밖에 가지지 못한다.

상속 관계 그리기 - 속이 비어 있는 화살표를 상위 클래스를 향해

 

6.3 상속의 잘못된 사용 - 상위 클래스 용도의 클래스가 아닌 구체 클래스를 상속받으면 안된다. 일반제품과 특수제품의 고유한 행동이 뒤섞인다.

 

6.4 추상화 찾아내기 - 하위클래스는 상위 클래스의 특수한, 구체적인 형태이다. 

추상화된 상위 클래스 만들기  

추상적인 행동을 위로 올리기 - 모든 제품이 쓰는 일반적인 행동을 위로 올린다. 구체적 행동을 아래로 x, 추상적 행동을 위로 올려라.

구체적인 것들 속에서 추상적인 것 분리해내기 - initializedptj super 전송이 뭘까

템플릿 메서드 패턴 사용하기 - 상위클래스에서 메시지를 전송하여 하위클래스의 특수한 값을 얻는 기술 (ex:기본값 정해주기)

모든 템플릿 메서드 구현하기 - notImplemented에러를 보내며 구현 해놓기, 유용한 에러메시지 겁나 중요!

 

6.5 상위클래스와 하위클래스 사이의 커플링 관리하기

커플링 이해하기 - 하위 클래스에서 super 전송을 강제하면 안된다.

훅 메시지를 사용해서 하위 클래스의 결합 없애기 - 초기화 방식을 알지 못해도 언젠가 초기화 된다는 사실만 알면 된다.

 

7장 모듈을 통한 역할 공유 - 하위 클래스끼리 조합한 클래스를 원한다면? 역할 공유의 또다른 방법

7.1 역할 이해하기 

역할 찾기 - 메시지가 많아지면 위험하다.

책임 관리하기 - 너무 많은 것을 알고 있으면 안된다.

불필요한 의존성 없애기 - 오리타입 찾아내기(변수 이름을 target 등으로 일반화하기), 객체가 자기 스스로를 표현할 수 있게 메서드 추가해 불필요한 의존성 없애기.

구체적인 코드 작성하기 - 작성 후 옮기기

추상화하기 - bicycle에 있던 schedulabe 모듈을 더 위로 뽑는다. 다른 탈 것이 사용해야 하기 때문에. 상속과 차이를 알아야 한다.

메서드를 찾아 올라가기 - 시간 갖고 이해하기.

역할의 행동 상속받기 - 모듈은 강력하다. 잘 써야 한다.

 

7.2 상속받을 수 있는 코드 작성하기

안티패턴 알아채기 - 같은 이름의 변수가 있다면, 객체 클래스를 확인하고 어떤 메시지를 전송할지 판단한다면, 

추상화된 코드를 모두 사용하기 - 나는 이런 것을 하지 않습니다 => 나는 이런 것이 아닙니다와 같다.

약속을 존중하라 - 상위 클래스가 사용될 수 있는 곳이라면 어디든 하위클래스가 사용될 수 있어야 한다.

템플릿 메서드 패턴 사용하기 - 추상적인 것과 구체적인 것 구분 가능. 어떤 것이 변하는 것이고 변하지 않는 것인지.

한발 앞서 클래스 사이의 결합 깨뜨리기 - 의존성 만들기 전에 깨뜨리기

상속관계(상속구조)를 낮게 만들기

 

8장 조합을 이용해 객체 통합하기 - 조합과 상속의 장단점

8.1 자전거 부품 조합하기

Bicycle 클래스 업데이트하기 - 

Parts의 상속 관계 만들기

 

8.2 Parts 객체 조합하기

Part 만들기

Parts를 배열과 비슷하게 만들기

 

8.3 Parts 생산하기

PartsFactory(부품 공장) 만들기

PartsFactory 발전시키기

 

8.4 조합된 Bicycle

 

8.5 상속과 조합 중 하나 선택하기

상속의 결과 받아들이기 - 모범이 된다.

조합의 결과 받아들이기 - 구조로부터 독립적

올바른 관계 선택하기 -

상속은 특수화이다.

상속은 이미 존재하는 클래스에 새로운 기능 추가할 때

주어진 행동이 자신 부분들의 총합 이상일 때 조합 쓰기

부품들을 가지고 있지만 그것이 모여서 단순한 부품모임 이상이 된다면 조합 사용하기

is-a 상속

behave-like-a 오리타입

has-a 조합

 

9. 비용 효율적인 테스트 디자인하기

리팩터링은 코드의 외적인 작동방식을 변경하지 않으면서 내부 구조를 발전시키는 것

 

9.1 의도를 가지고 테스트하기

테스트 의도를 알기

무엇을 테스트할지 알기

언제 테스트할지 알기

어떻게 테스트할지 알기

 

9.2 들어오는 메시지 테스트하기

사용하지 않는 인터페이스 제거하기

퍼블릭 인터페이스 검증하기

테스트중인 객체 고립시키기

클래스를 사용해서 의존성 주입하기

역할에 대한 의존성 주입하기

 

9.3 프라이빗 메서드 테스트하기

테스트 과정에서도 프라이빗 메서드 무시하기 - 몰라야 하는 메서드다. 외부에서 원래 없어야 하는 메소드다. 얘를 테스트하고 싶다는 것은 퍼블릭에서 무언가를 못하는 것일 가능성이 높다.  

테스트 중인 클래스에서 프라이빗 메서드 제거하기

프라이빗 메서드를 테스트하기

 

9.4 밖으로 나가는 메시지 테스트하기

쿼리 메시지 무시하기

커맨드 메시지 검증하기

9.5 오리 타입 테스트하기

역할 테스트하기

테스트 더블을 확인하기 위해 역할 테스트 사용하기

 

9.6 상속받은 코드 테스트하기

상속받은 인터페이스 명확히 하기

하위클래스의 책임 명확히 하기

하나뿐인 행동 테스트하기

 

 

테스트를 짜야 하는 이유는?

변경했을 때, 변경사항이 코드에 어떤 영향을 주는지 테스트가 확인해준다.

테스트를 통해 어떻게 동작하는지 기술할 수 있다.

어디가 고장났는지 빠르게 확인하여 비용을 줄여준다.

코드를 빠르게 사용해볼 수 있다.

테스트가 어렵다는 것은 사용하기 어렵다는 것

결정을 미룰 수 있다.

추상화를 돕는다.

디자인의 결점을 발견할 수 있다.