구현패턴 의문사항 정리

대칭성1

p.42

때로 대칭성을 찾아서 표현하면 코드의 중복을 제거할 수 있다. 코드 곳곳에서 비슷한 아이디어가 사용되었다면 대칭성에 따라 아이디어를 일관된 방식으로 표현해야 한다. 이렇게 되면 하나의 구현으로 통합할 수 있어서 중복되는 구현을 제거하기 쉬워진다.

이해됨

추상클래스

p.60

클래스 계층에서 최상위에 위치한 클래스를 인스턴스화 해서 사용할 가능성이 조금이라도 있다면 그렇게 하라. 추상화를 진행하다 보면, 쓸데없이 추상클래스를 너무 많이 만들게 되는 경우가 생긴다, 최상위 클래스를 인스턴스화 가능한 클래스로 만들면 이런 쓸데없는 추상 클래스 계층을 제거할 수 있다.

이해됨

외재 상태

p.90

때로 프로그램의 일부에서만 객체의 특정 상태를 필요로 하는 경우가 있다. 예를들어 객체가 디스크의 어느 부분에 저장되어 있느냐 하는 정보는 데이터 입력을 담당하는 부분을 제외한 프로그램의 다른 부분에는 의미가 없다. 필드를 통해 이러한 데이터를 저정하면 대칭성의 원리를 위배하게 된다. 다른 필드는 시스템 전체에 모두 유용하게 사용되기 때문이다.

어떤 객체와 관련된 특수 목적 정보는 객체가 아니라 그 객체를 필요로 하는 부분에 저장하는 편이 낫다. 앞에서 언급한 예의 경우, 데이터 입출력을 담당하는 부분에 IdentityMap이라는 맵을 만들고, 객체를 키로 디스크 상에 저장된 위치를 데이터로 사용하면 된다.

외재 상태를 사용하면 객체의 복사가 어려워진다. 외재 상태를 사용한 객체를 복사하는 것은 필드를 사용한 객체를 복사하는 것에 비해 복잡하다. 모든 외지 상태를 올바르게 복사하려면 상태를 어떻게 사용하는지 알아야한다. 또한 외재 상태를 사용하면 디버깅도 어려워진다. 일반적인 디버거는 객체의 외재 상태를 보여주지 않는다. 이런 문제 때문에 외재 상태를 사용하는 경우는 많지 않다. 하지만 적절하게 사용할 경우 외재 상태는 매우 유용하게 사용될 수 있다.

이해안됨

역할 제시형 작명

p.102~103

요컨대 나는 변수 이름을 통해 변수의 역할을 전달한다. 변수에 관한 다른 중요한 정보-생명기간, 범위, 타입-는 일반적으로 문맥(Syntax)을 통해 전달할 수 있다.

이해안됨 : 범위(Scope)는 변수의 접근제어자와 static 등으로로, 타입(Type)은 변수의 선언타입으로 알 수 있는데, 생명기간(LifeCycle)은 어떻게 전달할 수 있는 것인가? 혹시 final로 알 수 있다는 것인가?

도우미 메소드

p.138

도우미 메소드의 마지막 목적은 공용 구문(common sub-expression)을 제거하는 것이다. 조그마한 특정 연산이 필요할 경우마다 도우미 메소드를 호출하면 해당 구문의 수정은 어렵지 않다. 하지만 같은 2-3줄의 코드가 필요한 경우마다 반복된다면, 잘 선택한 이름을 통해 프로그래머의 의도를 부각시킬 수 없을 뿐 아니라 코드 수정도 어려워진다.

이해됨

호환성을 유지하는 업그레이드

p.182

한 가지 결정해야 할 사항은 어떤 종류의 호환성을 제공하는가 하는 것이다. 후방 호환성(backward compatibility) 업그레이드를 통해 프레임워크에 구형 메소드 호출과 구형 객체 전달을 지원할 것인가? 아니면 전방 호환성(forward compatibility) 업그레이드를 통해 신형 스타일의 객체를 클라이언트에 전달해도 동작하도록 할 것인가?

이해안됨