[BOOK] 객체지향의 사실과 오해

[BOOK] 객체지향의 사실과 오해 – 조영호 지음

부제: “역할, 책임, 협력 관점에서 본 객체지향”

사내 개발자 필독도서 시리즈 – 3편

제가 이 책을 쓰기 시작한 이유는 지금도 집필 중인 다른 책을 이해하는 데 필요한 개념과 배경 지식을 제공하고 싶었기 때문입니다. (p. 9)

집필중인 ‘오브젝트’가 출판되었네요. (예약판매시점에 다시 읽고, 글을 쓰려고 했으나, 흑)
OOP의 개념을 쉽게 설명한 책으로 신입개발자들에게 추천하고 있습니다. 최근에는 함수형으로 개발을 진행하는 프로젝트들도 있지만 열심히 유지보수를 하고 있는 기존 프로젝트들은 대부분 OOP로 설계/구현되어 있는 경우가 많습니다.

훌륭한 객체지향 설계란 겉모습은 아름답지만 협력자들을 무시하는 오만한 객체를 창조하는 것이 아니라 조화를 이루며 적극적으로 상호작용하는 협력적인 객체를 창조하는 것이다. 비록 그 객체를 따로 떼어놓고 봤을 때는 겉모습이 다소 기묘하고 비합리적이더라도 말이다. (p. 109)

1. 이 책은 객체지향을 다루는 다른 책이나 자료들을 읽을 때 미리 알고 있으면 도움될 만한 기본 배경과 지식을 다루는 책입니다. (p. 10)
2. 요청과 응답을 통해 다른 사람과 협력할 수 있는 능력, 협력하는 과정속에서 특정한 역할을 부여받고, 역할이라는 단어는 의미적으로 책임이라는 개념을 내포한다. (p. 27)
3. 객체지향 설계라는 예술은 적절한 객체에게 적절한 책임을 할당하는 것에서 시작된다. (p.30)
4. 객체지향 애플리케이션의 윤곽을 결정하는 것은 역할, 책임, 협력이지만 실제로 협력에 참여하는 주체는 객체다. (p.31)
5. 객체지향의 핵심은 클래스가 아니다. 핵심은 적절한 책임을 수행하는 역할 간의 유연하고 견고한 협력 관계를 구축하는 것이다. (p. 38)
6. 객체지향 패러다임의 목적은 현실 세계를 모방하는 것이 아니라 현실 세계를 기반으로 새로운 세계를 창조하는 것이다. (p. 42)
7. 객체를 상태(state), 행동(behavior), 식별자(identity)를 지닌 실체로 보는 것이 가장 효과적이다. (p.47)
8. 객체지향의 기본 사상은 상태와 상태를 조작하기 위한 행동을 하나의 단위로 묶는 것이라는 점을 기억하라. (p. 52)
9. 객체는 스스로의 행동에 의해서만 상태가 변경되는 것을 보장함으로써 객체의 자율성을 유지한다. (p. 52)
10. 객체의 행동에 의해 객체의 상태가 변경된다는 것은 행동이 부수 효과(side effect)를 초래한다는 것을 의미한다. (p. 52)
11. 객체가 필요한 이유는 애플리케이션의 문맥 내에서 다른 객체와 협력하기 위해서다. (p. 65)
12. 현실을 닮아야 한다는 어떤 제약이나 구속도 없다. (p. 71)
13. 사람들은 본능적으로 이해하기 쉽고 예측 가능한 수준으로 현실을 분해하고 단순화하는 전략을 따른다. (p. 76)
14. 객체에서 중요한 것은 객체의 행동이다. (p. 92)
15. 객체를 결정하는 것은 행동이다. 데이터는 단지 행동을 따를 뿐이다. (p. 95)
16. 객체지향 애플리케이션을 설계하고 구현하기 위해서는 객체 관점의 동적 모델과 객체를 추상화한 타입 관점의 정적 모델을 적절히 혼용해야 한다. (p. 104)
17. 객체지향 개발에서 가장 중요한 능력은 책임을 능숙하게 소프트웨어 객체에 할당하는 것 (p. 115)
18. 협력이라는 문맥에서 객체가 수행하게 될 적절한 책임, 즉 행동을 결정한 후에 그 행동을 수행하는 데 필요한 데이터를 고민해야 한다. (p. 129)
19. 디자인 패턴은 공통으로 사용할 수 있는 역할, 책임, 협력의 템플릿이다. (p. 136)
20. 테스트-주도 개발은 책임-주도 설계의 기본 개념을 따른다. (p. 137)
21. 객체지향 패러다임이 강력한 이유는 다형성을 이용해 협력을 유연하게 만들 수 있기 때문이라는 점을 기억하라. (p. 152)
22. 자주 변경되는 기능이 아니라 안정적인 구조를 따라 역할, 책임, 협력을 구성하라. (p. 180)
23. 변경에 유연한 소프트웨어를 만들기 위해서는 유스케이스에 정리된 시스템의 기능을 도메인 모델을 기반으로 한 객체들의 책임으로 분배해야 한다. (p. 197)
24. 소프트웨어는 항상 변한다. 설계는 변경을 위해 존재한다. (p. 227)