- 스터디 중 삼색볼펜법으로 체크한 부분들을 팀원들과 공유한 내용입니다.
- 스터디원들이 2명 이상 겹치는 부분은 강조표시(BOLD)가 되어 있습니다.
- 문장은 페이지의 오름차순으로 정렬되어 있습니다.
- 책임은 객체의 입장이 아니라 객체가 참여하는 협력에 적합해야 한다. (135)
- 함께 초기화되는 속성을 기준으로 코드를 분리해야 한다. (152)
- 동일한 문제를 해결할 수 잇는 다양한 책임 할당 방법이 존재하며, 어떤 방법이 최선인지는 상황과 문맥에 따라 달라진다. (133)
- 객체에게 중요한 것은 데이터가 아니라 외부에 제공하는 행동이다. (134)
- 데이터보다 행동을 먼저 결정하라 (134)
- 협력이라는 문맥 안에서 결정하라 (134)
- 객체가 메시지를 선택하는 것이 아니라 메시지가 객체를 선택하게 해야 한다. (135)
- 올바른 객체지향 설계는 클라이언트가 전송할 메시지를 결정한 후에야 비로소 객체의 상태를 저장하는 데 필요한 내부 데이터에 관해 고민하기 시작한다. (136)
- 설계를 시작하기 전에 도메인에 대한 개략적인 모습을 그려 보는 것이 유용하다. (137)
- 도메인 개념을 정리하는 데 너무 많은 시간을 들이지 말고 빠르게 설계와 구현을 진행하라. (138)
- 어떤 방식이건 정보 전문가가 데이터를 반드시 저장하고 있을 필요는 없다는 사실을 이해하는 것이 중요하다. (139)
- 객체의 책임과 책임을 수행하는 데 필요한 상태는 동일한 객체 안에 존재해야 한다. (139)
- 다시 말해 두 협력 패턴 중에서 높은 응집도와 낮은 결합도를 업을 수 있는 설계가 있다면 그 설계를 선택해야 한다는 것이다. (143)
- 하나의 클래스가 여러 타입의 행동을 구현하고 있는 것처럼 보인다면 클래스를 분해하고 POLYMORPHISM 패턴에 따라 책임을 분산시켜라. (159)
- 요소들 사이의 의존성의 정도가 유연성의 정도를 결정한다. (165)
- 이처럼 이해하기 쉽고 수정하기 쉬운 소프트웨어로 개선하기 위해 겉으로 보이는 동작은 바꾸지 않은 채 내부 구조를 변경하는 것을 리팩터링이라고 부른다. (166)
- 응집도 높은 메서드는 변경되는 이유가 단 하나여야 한다. (168)
- 작고, 명확하며, 한 가지 일에 집중하는 응집도 높은 메서드는 변경 가능한 설계를 이끌어 내는 기반이 된다. (171)
- 사실 객체지향 프로그래밍 언어를 이용해 절차형 프로그램을 작성하는 대부분의 이유가 바로 책임 할당의 어려움에서 기인한다. (165)