BookReview [오브젝트: 지은이의 글]

읽은 기록

오브젝트

객체지향의 사실과 오해를 읽고 조영호 저자님의 객체지향 다음 단계 책인 오브젝트를 찾게되었다.

객사오와 마찬가지로 혼자 읽기보다 내가 진행하고 있는 책읽기 스터디에서 진행했으며 정말 재밌고, 배운점도 많았던 책이다. 확실한 점은 설계 관련 책은 읽을 때 마다 새로 배우는 점이 많다는 것이다.

실제로 끝나고 나서 스터디원끼리 도메인 분석 스터디를 1회차 진행해봤다.

블로그에 통합본으로 올리기에 너무 커서.. 챕터마다 나눠서 올리기로 했다.

지은이의 글

저와 함게하는 짧지만 즐거운 두 번째 여행에 동참하신 것을 환영합니다.
:저자 조영호

첫 번째 책인 객체지향의 사실과 오해를 읽었다면 객체지향으로 향하는 첫 번째 걸음과 두 번째 걸음을 이해한 것이다. (객체지향 패러다임의 핵심은 객체이며, 객체는 독립적인 존재가 아니라 적절한 책임을 수행하며 협력하는 공동체의 일원이라는 사실)

이 책은 세 번째 걸음과 네 번째 걸음인 객체에 적절한 책임을 부여하면서 유연하고 그리고 요구사항에 적절한 협력을 설계하는 방법을 주로 다룬다.

모든 소프트웨어 책이 그러하듯 정답은 없다. 객체지향은 접근법, 구현법에 따라 동작은 같아도 매번 다른 구현방식이 나오곤 한다. 이 책을 통해 그 깊이를 탐구하고 가능성의 영역을 이해하자.

흔히 교조주의, 확증편항과 같이 자신이 알고있는 지식이나 배우는 지식이 정답이라 생각하면 안된다. 정답에 가까워지는 과정만 있을 뿐이다.

소프트웨어 개발의 역사가 시작된 이래로 등장한 거의 모든 프로그래밍 패러다임과 언어, 기술, 방법론은 소프트웨어 개발 중에 필연적으로 마주하게 되는 복잡함이라는 문제를 해결하려는 공통적인 목표를 공유한다. 개발자는 복잡한 코드를 이해하기 쉬운 관점으로 바라볼 수 있는 방법이 있다면 이를 더 손쉽게 다룰 수 있다는 것을 일게 됐다. (추상화한다.)

시스템을 독립적인 기능을 담당하는, 재사용 가능한 프로시저의 구성으로 보는 방법이 그중 하나다. 이와 다르게 시스템을 객체의 구성으로 보는 방법이 있다. 객체에게 명령 대신 요청을 담은 메시지를 전달하면 객체는 이를 어떻게 처리할지 자율적으로 판단하고, 내부에 가지고 있는 데이터를 이용해 필요한 작업을 수행하는 방식이다.

책임과 권한을 가진 객체들이 서로 메시지를 주고받으며 협력해서 필요한 기능을 수행하도록 시스템을 개발하는 객체지향 프로그래밍(OOP)이다.

하지만 요즘 개발자들은 객체지향의 이점(복잡함을 줄이는)을 효과적으로 사용하지 못하고 있다. 개부분 서버 플랫폼, 라이브러리, 알려진 기법(FSM)등과 같은 객체지향의 원칙보다 당장 사용가능한 영역이 더 돋보이고 있다.

하지만 이를 이해하고 활용하기 위해선 객체지향에 대한 이해가 가장 먼저 필수적이고 선행되어야 한다.

실제로 객체지향에 대한 이해없이 패턴이나 게임 알고리즘을 공부는 도움이 되지 못한 것 같다. 순서의 차이라고 생각한다.

이 책의 대상 독자

이 책은 어느정도 객체지향의 개념과 용어에 익숙한 사람이 읽는 것을 추천한다. (하나 이상의 객체지향 언어에 익숙) 프로젝트 경험이 어느정도 있어야 한다.

• 객체지향 프로그래밍의 기본적인 이론이나 개념에 대한 설명을 생략하고 곧장 동작하는 코드부터 설명한다. (패러다임에 익숙하지 않다면 책에서 본질적으로 전달하려는 내용을 이해하기 어렵다.)
• 이 책의 목적은 프로그램을 작성하는 방법을 설명하는 것이 아닌 좋은 설계란 무엇인가?에 대해서 설명하는 책이다. 따라서 익숙하지 않다면 오히려 악영향 일 수 있다.
• 이 책은 실무에서 객체지향 프로그래밍을 적용하는 시점에 직면할 수 있는 다양한 문제에 관해 설명한다. 경험이 없다면 추상적인 이론의 나열로 밖에 보이지 않는다.

이 책은 15개의 장과 4개의 부록으로 구성돼 있다.

• 1장 ‘객체, 설계’에서는 티켓 판매 시스템이라는 간단한 도메인을 예로 들어 책의 전체적인 주제를 함축해서 전달한다.
• 2장 ‘객체지향 프로그래밍’에서는 책 전반에 반복하게 될 영화 예매 시스템의 도메인을 설명하고 객체지향적으로 작성한 코드를 소개한다.
• 3장 ‘역할, 책임, 협력’에서는 2장에서 구현된 시스템의 역할, 책임, 협력의 관점에서 설명하고, 이 요소들을 이용해 시스템을 설계하는 책임 주도 설계 방법에 관해서도 소개한다.
• 4장 ‘설계 품질과 트레이드 오프’에서는 절차적 프로그래밍 방식으로 영화 예매 시스템을 다시 구현해보고 나쁜 품질에 대해서 이야기 한다.
• 5장 ‘책임 할당하기’에서는 GRASP라고 부르는 책임 할당 패턴을 설명한다. 2장에서 소개한 영화 예매 시스템의 설계를 책임 할당의 관점에서 설명하고 이를 4장의 구현과 비교한다.
• 6장 ‘메시지와 인터페이스’에서는 훌륭한 퍼플릭 인터페이스를 작성하기 위해 따라야 하는 설계 원칙을 소개한다.
• 7장 ‘객체 분해’에서는 추상화의 한 가지 방법인 분해의 역사를 다룬다. 프로시저 추상화와 데이터 추상화 사이의 갈등과 분쟁의 역사를 이해하면 기능 분해에서 시작해서 객체지향에 이르기까지 소프트웨어 패러다임에 대한 이해를 하게 될 것이다.
• 8장 ‘의존성 관리하기’에서는 의존성의 개념을 자세히 설명하고 결합도를 느슨하게 유지할 수 있는 다양한 설계 방법들을 설명한다.
• 9장 ‘유연한 설계’에서는 8장의 기법들이 원칙이라는 관점에서 정리한다.
• 10장 ‘상속과 코드 재사용’에서는 객체지향의 대표적인 재사용인 상속에 대해서 다룬다.
• 11장 ‘합성과 유연한 설계’에서는 코드를 재사용하기 위해 상속 대신 사용할 수 있는 기법인 합성을 소개한다.
• 12장 ‘다형성’에서는 객체지향의 핵심 메커니즘 중 하나로 불리는 다형성에 관해 다룬다.
• 13장 ‘서브클래싱과 서브타이핑’에서는 슈퍼타입과 서브타입의 개념을 설명하고 타입 계층을 만족시키기 위해 적용할 수 있는 원칙을 설명한다.
• 14장 ‘일관성 있는 협력’에서는 유사한 요구사항을 구현하기 위해 협력 패턴을 적용하면 이해하기 쉽고 유연하게 만들 수 있다는 사실을 알아본다.
• 15장 ‘디자인 패턴과 프레임워크’에서는 설계를 재사용하는 디자인 패턴과 설계와 코드를 재사용하는 프레임워크에 관해 알아본다.
• 부록 A ‘계약에 의한 설계’에서는 객체들이 협력을 위해 따라야 하는 약속을 계약의 관점에서 설명한다.
• 부록 B ‘타입 계층에 구현’을 읽고 나면 상속이 아닌 다른 방법으로도 타입 계층을 구현할 수 있다는 사실을 알게된다.
• 부록 C ‘동적인 협력, 정적인 코드’에서는 정적인 코드가 동적인 협력을 이끄는 것이 아니라 동적인 협력을 기반으로 정적인 코드를 구성해야 한다는 사실을 설명한다.
• 부록 D ‘참조문헌’에서는 책을 집필하면서 참고한 자료들을 소개한다.

들어가며: 프로그래밍 패러다임

객체지향 패러다임은 은총알이 아니다. 객체지향이 적합하지 않은 상황에서는 언제라도 다른 패러다임을 적용할 수 있는 시야를 기르고 갈고 닦아야 한다.

프로그래밍 패러다임은 특정 시대의 어느 성숙한 개발자 공동체에 의해 수용된 프로그래밍 방법과 문제 해결 방법, 프로그래밍 스타일이라고 할 수 있다. 간단히 말해서 우리가 어떤 프로그래밍 패러다임을 사용하느냐에 따라 우리가 해결할 문제를 바라보는 방식과 프로그램을 작성하는 방법이 달라진다.

프로그래밍 패러다임은 개발자 공동체가 동일한 프로그래밍 스타일과 모델을 공유할 수 있게 함으로써 불필요한 부분에 대한 의견 충돌을 방지한다. 또한 프로그래밍 패러다임을 교육시킴으로써 동일한 규칙과 방법을 공유하는 개발자로 성장할 수 있도록 준비시킬 수 있다.

다만 프로그래밍 영역에서의 패러다임은 공존이 가능하다는 점이다. 절차형 패러다임에서 객체지향 패러다임으로 전환됐다고 해서 두 패러다임이 함께 존재할 수 없는 것은 아니다. 오히려 서로 다른 패러다임이 하나의 언어 안에서 공존함으로써 서로 장단점을 보완하는 경향을 보인다.

객체지향 패러다임은 절차형 패러다임의 단점을 보완했지만 절차형 패러다임의 기반 위에서 구축됐다. 따라서 절차형 패러다임 객체지향 패러다임을 비교하는 것은 가능하며 이 역시 설명을 위해 두 가지 모두 비교할 것이다.

간단하게 프로그래밍 패러다임은 혁명적이 아니라 발전적이다.