최근에 팀 리더 분께서 객체지향의 사실과 오해라는 책을 추천해주셨습니다. 이 글을 쓰는 이유는 단지 책을 읽으면서 느꼈던 내 생각이나 중요하다고 판단되는 주간적인 내 생각을 정리하기 위해서 작성한 글이라 가볍게 봐주시면 감사하겠습니다. 해당 내용은 책, 71page 까지의 분량을 읽고 쓴 내용을 정리했으며 앞으로 지속적으로 읽고 업데이트 할 예정입니다.
[1] 협력하는 객체들의 공동체
책은 일상생활 속 커피를 주문하는 상황을 예시로 들면서 시작합니다. 커피를 주문하는 상황속 등장인물은 주문자, 캐시어, 바리스타로 구분됩니다. 책에서는 주문자, 캐시어, 바리스타가 각자의 책임과 역할을 다 해야한다고 서술합니다. 즉, 주문자는 커피를 주문할 책임을 캐시어는 주문을 받아서 바리스타에게 커피 제조 요청을 할 책임을, 바리스타는 커피를 제조할 책임을 갖습니다.
이 협력관계는 요청과 응답으로 구성되어 있고 하나의 문제를 해결하기 위해(여기서는 커피 주문) 요청은 연쇄적으로 작용되며 요청을 받은 사람은 주어진 책임을 다하고 요청에 응답해야 합니다. 책에서는 협력에서 차지하는 책임과 의무에 대해서 설명합니다.
- 여러 사람이 동일한 역할을 수행할 수 있다.
- 역할은 대체 가능성을 의미한다.
- 책임을 수행하는 방법은 자율적으로 선택가능하다.
- 한 사람이 동시에 여러 역할을 수행할 수 있다.
책임을 수행하는 방법이 자율적이라는 말의 의미는 요청에 대해 각자 다른 방식으로 응답할 수 있는 능력이라고 해석했고 이를 다른 말로 다형성이라고 부른다고 합니다. 이 책을 읽으면서 좋았던 점들 중 하나는 그동안 객제지향에 대해서, 그리고 개발에 대해서 추상적으로 이해하고 있던 개념들을 간단한 예시를 활용해 명확하게 개념을 정의해준다는 점에서 학습하면서 생겼던 모호함들이 사라졌던것 같습니다.
이어서 책에서 시스템은 역할과 책임을 수행하는 객체로 분할 되고 시스템의 기능은 객체간의 연쇄적인 요청과 응답의 흐름으로 구성된 협력으로 구현된다라고 서술합니다. 그러면서 객체의 두가지 덕목에 대해 이렇게 정의합니다.
- 객체는 충분히 협력적이어야한다.
- 객체는 충분히 자율적이어야한다.
객체가 협력적이라는 건 다른 객체에 수동적이지 않고 요청에 대해 응답할 수 있는 능력을 지녀야 함을 의미하는 것이고, 자율적이라는 건 자기 스스로의 원칙에 따라 어떤 일을 하거나 자기 스스로 통제하며 절제해야 함을 의미합니다.
책을 읽어가면서 가장 많이 들었던 생각 중 하나는 책임과 역할에 대한 고민이었습니다. 일을하면서 유지보수 하기 힘들다고 생각했던 소스의 특징은 하나의 객체가 많은 책임과 역할을 수행하고 있다는 점이었습니다. 현재 저희 회사에서는 고객의 판매처별로 주문을 수집하고 판매처 발송처리까지 하는 일련의 과정을 모두 한 controller에서 담당하고 있습니다.
각 판매처마다 제공하는 데이터의 의미, 데이터 타입, 값의 형식등이 모두 다르기 때문에 판매처별로 주문수집 부터 발송처리까지의 과정을 판매처에 맞게 수집되고 처리되도록 설계가 되어있었습니다. 문제는 인터페이스의 역할인데 인터페이스가 주문수집부터 발송처리의 모든 요청과 응답에 대한 인터페이스의 역할을 담다하고 있어서 코드의 길이가 길어지고 가독성이 떨어지며 심지어는 판매처 종속적인 코드가 인터페이스 내에 들어가는 상황이 발생하게 되었습니다.
각각 주문에 대해서 처리하는 로직이 다른 만큼 인터페이스를 분리해서 책임과 역할을 보다 분명히 할 수 있도록 설계한다면 가독성이 향상되고 판매처의 고유 특성으로 부터 완전히 독립적인 인터페이스가 설계될 것이라고 느꼈습니다.
다시 돌아와 책에서는 객체를 다음과 같이 정의하고 있습니다.
객체는 외부에서 접근이 허락된 수단을 통해서만 객체와 의사소통해야한다.
객체는 다른 객체가 무엇을 수행하는지 알 수 있지만 어떻게 수행하는지에 대해서는 알 수 없다.
외부의 요청이 무엇인지를 표현하는 메시지와 요청을 처리하기 위한 구체적인 방법인 메서드를 분리하는 것은 객체의 자율성을 높이는 핵심 메커니즘이라고 서술합니다. 다른 객체가 어떻게 수행하는지에 대해 알기 시작하는 순간 그 객체는 종속적 관계를 유발할 수 있다고 생각이 들었습니다. 예를들어 A객체가 B객체의 상태값을 직접적으로 알아야 하는 구조라면 B의 상태 가능성은 A 에게 큰 영향을 미칠 수 있습니다. A는 단지 B에게 요청을 내릴 책임만 있으며 B 역시 마찬가지입니다.
1장에서는 객체지향 = 클래스 로 보는것을 경계해야 한다고 지적합니다. 클래스가 객체지향적 설계를 위한 좋은 도구인것은 맞지만 지나치게 클래스를 강조하는 프로그래밍 언어적인 관점은 객체의 캡슐화를 저해하고 클래스를 서로 강하게 결합시킬 수 있다고 서술합니다.
즉, 코드를 담는 클래스 관점에서 메시지를 주고 받는 객체의 관점으로 전환해야한다고 주장하고 있습니다.
[2] 이상한 나라의 객체
2장은 우리에게 익숙한 이상한 나라의 엘리스의 이야기를 소개합니다. 엘리스의 이야기중 아름다운 정원에 들어가기 위해서 엘리스의 키를 줄이고 늘리는 상황을 예시로 들었고 다음과 같이 정리하고 있습니다.
- 엘리스가 키를 줄이기 위한 행동의 결과는 엘리스의 상태(키)에 의존적이다.
- 엘리스는 상태를 가지며 상태는 변경가능하다.
- 행동의 결과는 상태에 의존적이며 상태를 이용해 서술할 . 수있다.
- 행동의 순서가 결과에 영향을 미친다.
- 엘리스는 어떤 상태에 있더라도 유일하게 식별가능하다.
이상한 나라의 엘리스의 이야기로 객체지향을 설명할 예시를 들 수 있다는 점에서 책이 굉장히 흥미로웠던 것 같습니다.
책에서는 객체의 다양한 특성을 효과적으로 설명하기 위해 객체를 상태, 행동, 식별자를 지닌 실체로 보는게 효과적이라고 서술합니다.
객체는 식별가능한 개체 또는 사물이며 구체적인 사물일 수도 있고 추상적인 개념일 수도 있다.
객체는 구별가능한 식별자, 특징적인 행동, 변경 가능한 상태를 가진다.
SW안에서 객체는 저장된 상태와 실행가능한 코드를 통해 구현된다.
이책을 읽으면서 한가지 분명해진점은 상태라는 개념이었습니다. 책에서는 상태를 이용하면 과거의 모든 행동 이력을 설명하지 않고도 행동의 결과를 쉽게 예측하고 설명할 수 있다고 서술합니다.
개발이라는게 이 객체의 상태 값을 끊임없이 생성하고 변경하는 작업이라고 생각이 드는 만큼 앞서 설명한 상태의 특징을 다시한번 상기하고 일을 해야하겠다는 생각을 하게된것 같습니다.
엘리스의 예시 엘리스는 음료를 마시고 키를 줄이거나 늘릴 수 있습니다. 실세계에서 음료는 인간에 의해 수동적으로 양이 변경되지만, 객체지향 세계에서는 음료는 자율적인 실체로써 자신의 상태값인 양을 스스로 변경할 수 있는 자율성을 갖습니다. 엘리스가 음료를 마셨다면 엘리스의 키를 변경할 자율성만 갖고 음료 객체의 양 상태를 변경할 권한은 없습니다. 양은 오로지 음료 객체만 상태를 변경할 자율성을 갖게 한다는 것이 중요한 포인트인 것 같습니다.
앞서 객체는 다른 객체의 상태에 직접 접근 및 상태 변경하는 것은 객체의 자율성을 침해할 수 있다고 했습니다. 그럼 간접적으로라도 객체의 상태를 변경하거나 조회할 방법이 필요한데 이때 필요한 개념이 행동이라고 소개합니다. 행동은 다른 객체를 하여금 간접적으로 객체의 상태를 변경하는 것을 가능하게 합니다.
행동과 상태 사이의 관계는 다음과 같습니다.
- 객체의 행동은 상태에 영향을 받는다.
- 객체의 행동은 상태를 변경시킨다.
행동의 두가지 관점에서
- 상호작용이 현재의 상태에 어떤 방식으로 의존하는가?
- 예) 엘리스의 키가 40cm라면 문을 통과할 수있다. -> 상태에 의존적인 행동
- 상호작용이 어떻게 현재의 상태를 변경시키는가?
- 예) 문을 통과한 후에 엘리스의 위치는 정원으로 바꿔야 한다.
즉, 객체의 행동은 객체가 협력에 참여할 수 있는 유일한 방법입니다.
메시지 송신자(엘리스)는 메시지 수신자(음료) 상태 변경에 대해서 전혀 알지 못하도록 설계해야 합니다. 객체가 외부에 노출하는 것은 상태가 아닌 행동 뿐이며 외부에서 객체에 접근할 수 있는 유일한 방법도 행동 뿐입니다. 또한 객체의 상태를 변경할 지 여부는 객체 스스로 결정하는 것입니다. 캡슐화의 핵심 덕목인것 같습니다. 이 챕터의 핵심은 객체들간의 협력관계에 있어서 객체는 행동을 통해서만 협력에 참여하는 것의 중요성인것 같습니다.
이 챕터의 마지막은 객체지향의 두번재 오해에 대해 설명합니다. 가장 충격을 받았던 문장이면서 근본적인 오해라고 생각이 들었던것 같습니다. 책에서는 객체지향은 현실세계의 모방이 아니라고 주장합니다. 학창시절 객체지향 수업을 받았을 때 가장 많이 들었던 말 중 하나가 현실세계의 모방이라는 문장이었습니다. 당연하게 받아들여지고 의심하지 않았지만 책을 읽으며 생각이 바뀌게 되었습니다 .
현실세계와 객체지향의 가장 큰 차이는 수동적인 존재가 소프트웨어에서 객체는 능동적으로 변한다는 사실이라고 설명합니다. 예를 들어 실세계의 상품의 가격계산은 상품 스스로 할 수 없는 수동적인 존재지만 객체지향 속 상품은 상품 스스로가 가격계산을 하는 것이 가능합니다.
현실세계와 객체지향 사이의 관계를 명확히 설명할 수 있는 단어는 모방이 아니라 은유라고 설명합니다. 현실속의 객체의 의미 일부가 소프트웨어 객체로 전달되기 때문에 프로그램 내의 객체는 현실속 객체에 대한 은유이며 참조한 객체의 특성을 상기시킬수만 있다면 현실속의 객체의 이름을 이용해 객체를 묘사할 수 있는것이 객체지향 설계라고 주장하고 있습니다.
이 챕터까지 글을 읽으며 간단히 요약하자만 3문장으로 줄일 수 있을 것 같습니다.
- 객체는 충분히 자율적이어야 하며 책임과 역할이 분명해야한다.
- 객체가 협력할 수 있는 유일한 방법은 행동이다.
- 현실세계와 객체지향의 관계는 모방이 아니라 은유다
'도서 > 객체지향의 사실과 오해' 카테고리의 다른 글
| [객체지향의 사실과 오해] 도서 리뷰 2차 (0) | 2024.03.24 |
|---|
