객체지향의 사실과 오해 (2독)

이상한 나라의 엘리스 이야기를 바탕으로 객체를 풀어낸다

 

  내 블로그 첫 책 리뷰인 본 책을 6년이 지난 지금 다시 읽어 본다. 그땐 1주일 만에 다 읽었다고 쓰여있는데, 이번엔 거의 한 달에 한 챕터씩 밖에 못 읽었다. 야속한 세월 탓을 해본다..

 

---

목차

• 01장: 협력하는 객체들의 공동체
• 02장: 이상한 나라의 객체
• 03장: 타입과 추상화
• 04장: 역할, 책임, 협력
• 05장: 책임과 메시지
• 06장: 객체 지도
• 07장: 함께 모으기
• 부록A 추상화 기법

 

---

  객체지향도 결국은 유지보수 때문이다. 소프트웨어는 일회성이 아니라 계속해서 진화하고 발전해 나가는 생물체와 같다. 계속적인 변화가 일어나는데 유지보수 비용이 계속 늘어난다면 그 소프트웨어는 가치를 잃어 갈 수밖에 없다. 계속해서 비용이 증가하는 시스템을 회사 입장에서도 탐탁지 않게 바라볼 수밖에 없을 것이다. 객체를 활용해서 유지보수성이 좋은 프로그램을 만드는 것, 그것이 객체지향의 본질이 아닌가 싶다.

 

  "자율적인 객체들이 서로 메시지를 활용해 협력해 프로그래밍을 하는 것"이 객체지향 프로그래밍이라고 이야기한다. 책의 전반에 걸쳐 계속 반복하며 강조한다. 객체는 섬이 아니고, 자율적이며, 스스로 구현을 결정할 수 있으며, 메시지를 통해 소통한다. 객체는 각자에게 가장 잘 맞는 책임과 역할을 부여하여 필요한 일을 해당 객체가 처리하도록 해야 한다. 그래서 갓클래스(한 클래스 파일 안에 역할 구분도 없이 매우 많은 기능들이 존재하는 전지전능한 클래스)는 악이라고 말한다. 명확히 구분된 책임과 역할로 객체를 쪼개야 하기 때문이다. 이는 자연스럽게 SRP를 지키게 되는 것이며 추후 변경 시에 변경점 파악에도 유리하다. 사내 소스에도 갓클래스 같은 XxxService가 존재한다. 당장 다 뜯어고치지는 못하지만 계속 줄여나갈 생각이다. 만들면서 배우는 클린 아키텍처를 읽고 나서부터는 XxxQueryService,  XxxCommandService로 분리해서 만든다. 변경과 조회에 관한 책임을 나누고자 함이다.

 

  인터페이스와 구현을 분리하는 것도 강조한다. 객체는 메시지를 통해 서로 소통을 하는데 소통의 창구가 인터페이스가 된다. 상세한 구현 자체는 객체 스스로가 능동적으로 결정할 수 있다. 자바에서 다형성인 인터페이스로 느슨한 설계를 하게 되면 구체 클래스는 호환이 가능하기 때문에 쉽게 갈아낄 수 있다. 인터페이스는 외부와 노출되는데 한 번 만들어진 이후에는 수정이 어려우므로 처음에 잘 고민하고 만들어야 한다. 이는 API를 만들 때도 똑같이 적용되는 이야기 같다.

 

  6년이 흘러 다시 보았지만 여전히 유용하며 객체지향 프로그래밍에 대해 이해하기 쉽게 잘 쓰여 있다고 느껴졌다. 소프트웨어를 더 가치 있고 유연하게 만드는데 도움이 되는 책이다.

 

 

 

객체지향의 사실과 오해: 역할, 책임, 협력 관점에서 본 객체지향, 조영호(위키북스)

객체지향의 사실과 오해 - YES24