티스토리

안녕하세요.

1. 책 선택 이유

 레뷰(REVU) 캠페인에 선정되어서 책을 보게 되었습니다. 

 장점만을 적기보다는 책 내용을 확인할 수 있게 정리해 보았습니다.

2. 목차 확인

​

3. 책 속 내용 확인

p5 - "객체지향 디자인을 두 가지 구체적인 각도에서 탐구한다. ... 첫째, 개발자의 작업 대부분은 기존 시스템을 유지하고 발전시키는 데 초점이 맞춰져 있다. ... 따라서 이 책은 자연스러운 복잡성 증가에 맞서 싸우는 방법을 주로 다룬다.

​

둘째, 처음에는 자신이 무엇을 구축하고 있는지 잘 모르는 경우가 많다. ... 이 책의 목적은 항상 절대적으로 가장 뛰어난 디자인을 만들어내도록 안내하는 것이 아니라, 여러분이 소프트웨어를 효과적으로 구축할 수 있도록 좋은 디자인을 만드는 방법을 알려주는 것이다."

-> 저자가 책을 쓴 의도를 명확하게 말해준다. 저자의 의도를 생각하고 읽어가면 좋을 것이다.

P25 - "객체지향 언어를 사용해 정보 시스템을 만드는 개발자들이 일반적으로 떠올리는 질문이다.

이 구현이 충분히 단순한가? 아니라면 더 우아한 추상화를 추가해야 할까? ... 이 클래스가 다른 클래스에 의존해도 좋을까? 그런 식의 결합은 나쁜 것일까?"

-> 객체지향(Object Oriented) 디자인하는 개발자라면 한 번쯤 고민하는 질문들이다. 질문에 대한 답을 알려준다고 생각하고 읽어 보면 된다.

p29 -

-> 객체(Object)에 대한 의존성 관계와 변화 전파를 그림으로 표현해 주고 최소화하는 방법을 설명해 간다.

p34 - "디자인을 단순하게 유지하는 것은 개발자의 책임이다. ... 단순함과 복잡성 사이의 적절한 균형을 찾는 것이 개발자의 임무이다."

-> 어떻게 보면 개발자만의 책임이라고 하기보다는 개발하고 연구하는 분야의 사람들의 책임과 임무가 아닐까 한다.

p39 -

-> 책의 예제 소스코드를 이해하기 위해서 위의 피플그로우 고수준 아키텍처를 이해하고 있어야 코드를 보는 데 도움이 된다.

p46 - "클래스병을 조심하라 ... 그는 작은 클래스가 너무 많아지는 것을 클래스병이라고 표현했다. 그의 주장에는 일리가 있다. 거대한 코드 블록을 원하지 않는 것만큼이나 아주 작은 클래스도 바람직하지 않다."

-> 클래스화 하는 것에 너무 집착하다 보면 이것도 하나의 병이라고 불릴 수 있겠구나 생각하게 하는 대목이다.

p75 -

-> 유효성 검증을 위한 컴포넌트에 설명을 해준다.

p92 -

-> 애그리게이트 루트를 보여주며 디자인은 내부 도메인 객체(Object) 수정이 불가능하도록 이뤄져야 한다는 것을 보여준다.

p101 -

-> 저수준의 코드는 고수준 인터페이스를 구현하며 구체적인 목적을 달성하는 단계를 보여준다.

p108 -

-> 개발자가 고민하는 것 중 기존 객체(Object) 클래스에 코드를 추가할지 새로운 객체(Object) 클래스를 만들어 진행할지에 따라 관계를 알려준다.

p135 -

-> 확장 지점과 추상화를 생성해야 할 때 결정하는 데 도움 될 수 있는 세 가지 경험적 규칙을 알려준다.

p144 -

-> 항상 인터페이스로 만들어야 하는 것은 아니다, 때로는 클래스 하나로도 충분하다 이럴 때 인터페이스를 언제 생성해야 할지 판단하는 저자의 경험적 규칙을 나타내고 있다.

​

<소스코드 참고 사이트>

<github 사이트>

1. https://github.com/gilbutITbook/080391

2. https://github.com/enshahar/SimpleObjectOrientedDesignCode