[서적] 객체지향의 사실과 오해 | 조영호

객체지향의 사실과 오해 | 조영호 - 교보문고

 

F-lab 프로젝트를 하면서 코드 리뷰를 받을 때 "메시지"를 보내는 주체가 되는 객체는 어떤 것이 되어야 하는지, 책임과 관심사를 제대로 분리했을 때 이전의 잘못된 코드에서 어떤 걸 개선할 수 있을지에 대한 걸 많이 배웠다. 원래도 오브젝트라는 책을 읽고 싶어서 읽기 전에 조금은 가벼운 마음으로 먼저 읽고 싶은 책이었는데 이 책의 부제가 <역할, 책임, 협력 관점에서 본 객체지향>이기 때문에 지금 읽으면 더 도움을 받을 수 있을 것 같아 읽기 시작했다. 

 

이 책은 몇 가지의 중요한 토픽을 반복적으로 설명하고 강조한다. 그래서 어렴풋이 이해는 했지만 정확히 정의내리기에는 어려웠던 개념들을 다양한 예제들을 통해서 익힐 수 있었다. 객체지향이라는 개념도 책을 읽고 나니 훨씬 명확해진 것 같다. 그리고 객체의 책임과 역할에 대해서 생각할 때 어떤 식으로 내가 사고를 해야 도움이 될지를 배울 수 있어서 좋았다.

 

---

01 협력하는 객체들의 공동체

객체지향의 핵심은 적절한 책임을 수행하는 역할 간의 유연하고 견고한 협력 관계를 구축하는 것이다.

객체지향의 본질을 이해하려면 책임, 역할, 협력에 대해 이해해야 한다. 자율적인 객체는 정해진 역할을 수행하고 역할은 그 책임의 집합으로 대체 가능해야 한다. 그리고 이 객체는 다른 객체와의 메시지 전송을 통해 서로 협력한다.

 

02 이상한 나라의 객체

객체는 스스로의 행동에 의해서만 상태가 변경되는 것을 보장함으로써 객체의 자율성을 유지한다.

객체는 식별 가능하며 상태와 행동을 가진다. 이때 행동에 의해서 상태가 변경될 수 있다. 그렇기 때문에 초점을 맞춰야 하는 것은 객체의 상태가 아닌 행동이다. 

 

03 타입과 추상화

객체를 분류하기 위해 타입을 결정한 후 프로그래밍 언어를 이용해 타입을 구현할 수 있는 한 가지 방법이 클래스라는 사실을 아는 것만으로도 충분하다.

추상화의 목적은 불필요한 부분을 무시함으로써 현실에 존재하는 복잡성을 극복하는 것이다. 타입을 이용하면 객체의 동적인 특성을 추상화할 수 있고 시간에 따른 객체의 상태 변경이라는 복잡성을 단순화할 수 있다.

 

04 역할, 책임, 협력

객체지향 설계는 협력에 참여하기 위해 어떤 객체가 어떤 책임을 수행해야 하고 어떤 객체로부터 메시지를 수신할 것인지를 결정하는 것으로부터 시작된다.

크레이그 라만(Craig Larman)은 "객체지향 개발에서 가장 중요한 능력은 책임을 능숙하게 소프트웨어 객체에 할당하는 것"이라고 말한다. 각 객체가 가져야 하는 상태와 행위에 대해 고민하기 전에 그 객체가 참여할 문맥인 협력을 정의하라. 객체지향 시스템에서 가장 중요한 것은 충분히 자율적인 동시에 충분히 협력적인 객체를 창조하는 것이다. 

 

05 책임과 메시지

객체지향 애플리케이션의 중심 사상은 연쇄적으로 메시지를 전송하고 수신하는 객체들 사이의 협력 관계를 기반으로 사용자에게 유용한 기능을 제공하는 것이다.

메시지는 송신자와 수신자 사이의 결합도를 낮춤으로써 설계를 유연하고, 확장 가능하고, 재사용 가능하게 만든다. 객체의 인터페이스에는 객체가 수신할 수 있는 메시지의 목록이 있고, 인터페이스를 통해 다른 객체로부터 메시지를 받으면 자신에게 할당된 책임을 수행할 수 있다. 이때 외부에서는 구현을 몰라야 하고 내부 로직이 변경되더라도 영향을 받지 않게 해야 한다.

 

06 객체 지도

안정적인 도메인 모델을 기반으로 시스템의 기능을 구현할 경우 시스템의 기능이 변경되더라도 비즈니스의 핵심 정책이나 규칙이 변경되지 않는 한 전체적인 구조가 한 번에 흔들리지는 않는다.

 

07 함께 모으기

개념 관점, 명세 관점, 구현 관점은 동일한 코드를 바라보는 서로 다르고나점이다. 훌륭한 객체지향 프로그래머는 하나의 클래스 안에 세 가지 관점을 모두 포함하면서도 각 관점에 대응되는 요소를 명확하고 깔끔하게 드러날 수 있다.

클래스가 은유하는 개념은 도메인 관점을 반영한다. 클래스의 공용 인터페이스는 명세 관점을 반영한다. 클래스의 속성과 메서드는 구현 관점을 반영한다. 캡슐화를 위반해서 구현을 인터페이스 밖으로 노출해서도 안 되고, 인터페이스와 구현을 명확하게 분리하지 않고 흐릿하게 섞어놓아서도 안 된다.