- 스터디 중 삼색볼펜법으로 체크한 부분들을 팀원들과 공유한 내용입니다.
- 스터디원들이 2명 이상 겹치는 부분은 강조표시(BOLD)가 되어 있습니다.
- 문장은 페이지의 오름차순으로 정렬되어 있습니다.
- 객체지향 설계의 핵심은 협력을 위해 필요한 의존성은 유지하면서도 변경을 방해하는 의존성은 제거하는 데 있다.
- 문제는 의존성의 존재가 아니라 의존성의 정도다.(265)
- 의존성은 명시적으로 표현돼야 한다.(271)
- 의존성은 방향성을 가지며 항상 단방향이다.
- 의존성이 실제로 전이될지 여부는 변경의 방향과 캡슐화의 정도에 따라 달라진다.
- 컴파일타임 의존성이라는 용어가 중요하게 생각하는 것은 시간이 아니라 우리가 작성한 코드의 구조이기 떄문이다.
- 코드 작성 시점의 Movie 클래스는 할인 정책을 구현한 두 클래스의 존재를 모르지만 실행 시점의 Movie 객체는 두 클래스의 인스턴스와 협력할 수 있게 된다.(259)
- 따라서 컴파일타임 구조와 런타임 구조 사이의 거리가 멀면 멀수록 설계가 유연해지고 재사용 가능해진다.(260)
- 클래스는 자신과 협력할 객체의 구체적인 클래스에 대해 알아서는 안 된다.(260)
- 클래스가 특정한 문맥에 강하게 결합될수록 다른 문맥에서 사용하기는 더 어려워진다.(260)
- 설계가 유연해지기 위해서는 가능한 한 자신이 실행될 컨텍스트에 대한 구체적인 정보를 최대한 적게 알아야 한다.(261)
- 이처럼 컴파일타임 의존성을 실행 컨텍스트에 맞는 적절한 런타임 의존성으로 교체하는 것을 의존성 해결이라고 부른다.(261)
- 항상 객체를 생성할 때 의존성을 해결해서 완전한 상태의 객체를 생성한 후, 필요에 따라 setter 메서드를 이용해 의존 대상을 변경할 수 있게 할 수 있다.(263)
- 메서드 인자를 사용하는 방식은 협력 대상에 대해 지속적으로 의존 관계를 맺을 필요 없이 메서드가 실행되는 동안만 일시적으로 의존 관계가 존재해도 무방하거나, 메서드가 실행될 떄마다 의존 대상이 매번 달라져야 하는 경우에 유용하다.(264)
- 어떤 의존성이 다양한 환경에서 재사용될 수 있다면 그 의존성은 바람직한 것이다.(265)
- 서로에 대해 알고 있는 지식의 양이 결합도를 결정한다.(267)
- 결합도를 느슨하게 만들기 위해서는 구체적인 클래스보다 추상 클래스에, 추상 클래스보다 인터페이스에 의존하도록 만드는 것이 더 효과적이다.(268)
- 유연하고 재사용 가능한 설계란 퍼블릭 인터페이스를 통해 의존성이 명시적으로 드러나는 설계다.(271)
- new는 결합도를 높이기 떄문에 해롭다.(273)
- 해결 방법은 인스턴스를 생성하는 로직과 생성된 인스턴스를 사용하는 로직을 분리하는 것이다.(273)
- 그리고 그 출발은 객체를 생성하는 책임을 객체 내부가 아니라 클라이언트로 옮기는 것에서 시작했다는 점을 기억하라.(274)
- 의존성이 불편한 이유는 그것이 항상 변경에 대한 영향을 암시하기 때문이다.(276)
- 따라서 의존성에 대한 영향이 적은 경우에도 추상화에 의존하고 의존성을 명시적으로 드러내는 것은 좋은 설계 습관이다.(276)
- 유연하고 재사용 가능한 설계는 객체가 어떻게(how)하는지를 장황하게 나열하지 않고도 객체들의 조합을 통해 무엇(what)을 하는지를 표현하는 클래스들로 구성된다.(280)
- 협력은 필수적이지만 과도한 협력은 설계를 곤경에 빠트릴 수 있다.
- 더 많이 알수록 더 많이 결합된다.(267)
- 다시 말해 의존성이 퍼블릭 인터페이스에 표현되지 않는다. 이를 숨겨진 의존성이라고 부른다.(270)
- 클래스가 다른 클래스에 의존하는 것은 부끄러운 일이 아니다.(271)
- 어떤 경우든 코드 내부를 직접 수정하는 것은 버그의 발생 가능성을 높이는 것이라는 점을 기억하라.(277)