객체지향의 사실과 오해 : 역할, 책임, 협력 관점에서 본 객체지향
https://m.yes24.com/Goods/Detail/18249021
1. 협력하는 객체들의 공동체
객체지향의 오해
“객체지향이란 실세계를 직관적이고 직접적으로 모델링 할 수 있는 패러다임이다.” 문장에서는 현실 세계의 사물을 보다 현실과 가깝게(완전하게) 모델링 하는 의미로 해석됩니다.
프로그래밍의 객체지향
프로그래밍에서 객체지향의 본질은 실세계를 모방하는 것이 아닙니다. 오히려 새로운 세계를 창조하려는 것 입니다. 소프트웨어 개발자의 역할은 단순히 설계서를 소프트웨어 안으로 옮겨 담는 것이 아니라 고객과 사용자를 만족시킬 수 있는 신세계를 창조하는 것 입니다.
객체지향의 본질
- 객체지향이란 시스템을 상호작용 하는 자율적인 객체들의 공동체로 바라보고 객체를 이용해서 시스템을 분할하는 방법이다.
- 자율적인 객체란 상태와 행위를 함께 지니며 스스로 자기 사자신을 책임지는 객체를 의미한다.
- 객체는 시스템의 행위를 구현하기 위해 다른 객체와 협력한다. 각 객체는 협력 내에서 정해진 역할을 수행하며 역할은 관련된 책임의 집합이다.
- 객체는 다른 객체와 협력하기 위해 메시지를 전송하고 메시지를 수신한 객체는 메시지를 처리하는데 적합한 메서드를 자율적으로 선택한다.
2. 이상한 나라의 객체
객체지향과 인지 능력
인간이 직접적으로 지각할 수 있는 대부분의 객체는 물리적인 경계를 지닌 구체적인 사물입니다. 그러나 인간의 인지 능력은 물리적인 한계를 넘어 개념적으로 경계지을 수 있는 추상적인 사물까지도 객체로 인식 할 수 있게 합니다. (EX 시간, 기분, 답답함의 정도)
세상을 더 작은 객체로 분해하는 것은 본질적으로 세상이 포함하고 있는 복잡성을 극복하기 위한 인간의 작은 몸부림 입니다. 인간은 좀 더 단순한 객체들로 주변을 분해함으로써 자신이 몸담고 있는 세상을 이해하려고 노력합니다.
객체 그리고 소프트웨어 나라
객체의 다양한 특성을 효과적으로 설명하기 위해서는 객체를 상태(State), 행동(Behavior) 식별자(identity)를 지닌 실체로 보는 것이 가장 효과적 입니다. 따라서 이 책에서는 객체를 다음과 같이 정의합니다.
💡 객체란 식별 가능한 개체 또는 사물 입니다. 자동차 처럼 만질 수 있는 구체적인 사물일수도 있고, 시간처럼 추상적인 개념일 수도 있습니다. 객체는 구별가능한 식별자, 특징적인 행동, 변경 가능한 상태를 가집니다. 소프트웨어 안에는 객체는 저장된 상태와 실행 가능한 코드를 통해 구현됩니다.
은유와 객체
의인화
실제 현실과 소프트웨어에서의 객체의 사장 큰 차이는 바로 “자율성” 입니다. 현실속에서는 수동적인 존재가 소프트웨어 세계에서는 능동적으로 구현된다는 점 입니다.
은유
현실속의 객체의 의미 일부가 소프트웨어 객체로 전달되기 때문에 프로그램 내의 객체는 현실속의 객체에 대한 은유입니다. 비록 현실 속의 전화기는 스스로 전화를 걸 수 없다고 하더라도 우리가 익히 알고 있는 현실의 전화기라는 개념을 이용해 소프트웨어 객체를 묘사하면 그 객체가 전화를 걸 수 있다는 사실을 쉽게 이해하고 기억할 수 있게 됩니다.
3. 타입과 추상화
추상화를 활용한 실제 사례
문제 상황
1930년 5개의 지하철 회사를 통폐합 하고 언더그라운드라는 새로운 브랜드로 공동 운영하게 된 런던 지하철은 전 노선을 쉽게 알아 볼 수 있는 지도를 만들기로 결정해습니다. 초기의 지하철 노선도는 실제와 유사한 물리저긴 지형 위에 구불구불한 운행 노선과 불규칙적인 역 간의 거리를 사실적으로 묘사하고 있었다. 문제는 이렇게 사실적인 정보가 지하철을 이용하는 승객으로 하여금 노선도를 이해하기 어렵게 만들었다는 점 입니다. 지하철 이용 승객의 목적은 하나의 역에서 다른 역으로 이동하는 것 입니다. 따라서 환승에 대한 정보와 어떤 Route가 가장 빠를지에 대한 정보를 제공하는 것 입니다. 하지만 아래와 같은 지도는 승객의 요구에 그다지 협조적이지 않은 모습입니다.
이와 반대로 1933년 헨리 백은 사실적인 지형과 축척은 무시하고 역 사이의 연결성에만 집중한 혁신적인 지하철 노선도를 창조했습니다. 모든 역 위의 위치와 거리도 부정확했으며 심지어 경로를 표시한 직서은은 실제로 지하철이 이동하는 경로와는 상관이 없었습니다.
헨리벡이 창조한 지하철 노선도의 핵심은 지도가 당연히 가져야 한다고 생각되는”정확성”을 버리고 그 “목적”에 집중한 결과 입니다. 헨리벡은 인터뷰에서 다음과 같이 밝혔습니다.
“이 지도는 상식에 근거한 것 입니다. 지하철을 갈아탈 때 지형 때문에 골치 아플 필요가 있을까요? 지형은 중요한 것이 아닙니다. 중요한 것은 연결, 즉 열차를 갈아타는 것 입니다.”
추상화를 통한 복잡성 극복
현실에 존재하는 다양한 현상 및 사물과 상호작용 하기 위해서는 현실을 이해해야 한다. 진정한 의미로 추상화란 현실에서 출발하되 필요한 부분을 도려내어가면서 사물의 놀라운 본질을 보여주게 하는 과정이라고 할 수 있다. [Root-Bernstein 2001]
책에서는 다음과 같이 추상화를 정의합니다.
💡 추상화
어떤 양상, 세부사항, 구조를 좀 더 명확하게 이해하기 위해 특정 절차나 물체를 의도적으로 생략하거나 감춤으로써 복잡도를 극복하는 방법이다.
복잡성을 다루기 위해 추상화는 두 차원에서 이뤄진다.
- 첫번째 차원은 구체적인 사물들 간의 공통점은 취하고 차이점은 버리는 일반화를 통해 단순하게 만드는 것 이다.
- 두번째 차원은 중요한 부분을 강조하기 위해 불필요한 세부사항을 제거함으로 단순하게 만드는 것이다.
모든 경우 추상화의 목적은 복잡성을 이해하기 쉬운 수준으로 단순화 하는 것을 의미합니다.
타입
타입의 정의는 개념의 정의와 완전히 동일하다. 타입은 공통점을 기반으로 객체를 묶기 위한 틀이다. 타입은 개념과 마찬가지로 심볼, 내연, 외연을 이용해서술 할 수 있으며 타입에 속하는 객체 역시 타임의 인스턴스 라고 합니다.
타입은 개념과 동일하다. 따라서 타입이란 우리가 인식하고 있는 다양한 사물이나 객체에 적용할 수 있는 아이디어나 관념을 의미합니다. 어떤 객체에 타입을 적용할 수 있을 때 그 객체를 타입의 인스턴스라고 한다. 타입의 인스턴스는 타입을 구성하는 외연의 객체 집합의 일원이 됩니다.
왜 타입을 사용해야 할까?
타입을 사용하는 이유는 인간의 인지 능력으로는 시간에 따라 동적으로 변하는 객체의 복잡성을 극복하기 너무 어렵기 때문입니다. 예를 들어 이상한 나라의 엘리스는 약이나 특정한 Event이후로 키가 늘거나 줄어듭니다. 타입은 이렇게 Event이후로 변하는 엘리스를 정적인 타입 형태로 다룰 수 있게 됩니다.
4. 역할 책임 협력
협력
협력은 한 사람이 다른 사람에게 도움을 요청할 때 시작합니다. 자신에게 할당된 일이나 업무를 처리하던 중에 스스로 해결하기 어려운 문제에 부딪히게 되면 문제를 해결하는데 필요한 지식을 알고 있거나 도움을 받을 수 있는 누군가에게 도움을 요청하게 됩니다. 요청을 받은 사람은 일을 처리한 후 요청한 사람에게 필요한 지식이나 를 제공하는 것으로 요청에 응답합니다.
협력은 객체가 행하는 책임과 관련이 있습니다. 가령 커피를 주문하는 시나리오를 생각해 보겠습니다. 손님은 바리스타에게 커피를 주문합니다. 손님은 어떤 커피를 마실지를 바리스타에게 전달하고, 바리스타는 손님의 요청에 대해 처리합니다.
이를 객체지향 렌즈를 끼고 바라보게 된다면, 손님은 바리스타에게 커피를 달라는 협력을 요구합니다. 그 이후에 바리스타는 손님에게 협력의 결과로서 커피를 줍니다. 바리스타의 책임은 당연히 커피를 만드는 것이고, 손님은 주문하는 것이 책임 입니다.
책임
협력에 참여하는 객체들은 목표를 달성하는데 필요한 책임을 수행합니다. 책임은 객체에 의해 정의되는 응집도 있는 행위의 집합으로 객체가 알아야 하는 정보와 객체가 수행할 수 있는 행위에 대해 개략적으로 서술한 문장입니다.
크레이그 라만은 객체의 책임을 크게 “하는 것” 과 “아는 것” 두가지 범주로 자세하게 분류합니다.
- 하는 것(doing)
- 객체를 생성하거나 계산을 하는 등의 스스로 하는 것
- 다른 객체의 행동을 시작하는 것
- 다른 객체의 활동을 제어하고 조정하는 것
- 아는 것
- 개인적인 정보에 관해 아는 것
- 관련된 객체에 관해 아는 것
- 자신이 유도하거나 계산할 수 있는 것에 관해 아는 것
책임과 메시지는 다를까
책임은 객체가 협력에 참여하기 위해 수행해야 하는 행위를 상위 수준에서 개략적으로 서술한 것입니다. 책임을 결정한 후에 실제로 협력을 정제하면서 이를 메시지로 변환할 때는 하나의 책임이 여러 메시지로 분할되는 것이 일반적입니다.
객체의 모양을 결정하는 협력
흔한 오류
많은 사람들은 시스템에 필요한 데이터를 저장하기 위해 객체가 존재한다는 선입견을 가지고 있다. 물론 객체가 상태의 일부로 데이터를 포함하는 것은 사실이지만 데이터는 단지 객체가 행위를 수행하는데 필요한 재료일 뿐입니다. 중요한 것은 객체의 행동, 즉 책임 입니다.
객체 지향의 두번째 선입견은 클래스와 클래스 관계를 포현하는 시스템의 정적인 측면에서 중점을 두는 것입니다.
5. 책임과 메시지
자율적인 책임
객체지향 공동체를 구성하는 기본 단위는 “자율적” 객체 이다. 객체들은 어플리케이션의 기능을 구현하기 위해 협려가혹, 협력 과정에서 각자 맡은 바 책임을 다하기 위해 자율적으로 판단하고 행동합니다. 객체가 어떤 행동을 하는 이유는 다른 객체로부터 요청을 수신했기 때문입니다. 요청을 처리하기 위해 객체가 수행하는 행동을 책임이라고 합니다. 따라서 자율적인 객체란 스스로의 의지와 판단에 따라 각자 맡은 책임을 수행하는 객체를 의미합니다.
적절한 책임이 자율적인 객체를 낳고 자율적인 객체들이 모여 유연하고 단순한 협력을 낳습니다. 따라서 협력에 참여하는 객체가 얼마나 자율적인지가 어플리케이션의 품질을 결정합니다.
너무 추상적인 책임
자율적인 책임을 위해 추상적인 책임 사용하게 된다면, 그것 또한 문제가 될 수 있습니다. 예를 들어 오늘 점심에 대해서 설명하라 라는 메시지를 설명하라 라고 일축하게 되면 너무나 추상적이여서 알아볼 수 없습니다. 따라서 적절한 추상화를 지키는 것 또한 중요합니다.
묻지 말고 시켜라
메시지를 먼저 결정하고 객체가 메시지를 따르게 하는 설계 방식은 객체가 외부 제공 인터페이스가 독특한 스타일을 따르게 합니다. 이 스타일을 묻지 말고 시켜라 스타일 또는 데메테르 법칙 이라고 합니다. 메시지를 먼저 결정하고 메시지에 적합한 객체를 선택하는 방식을 따르다 보면 객체 사이의 협력 방식을 특정짓는 한가지 스타일에 이르게 됩니다. 송신자는 수신자가 어떤 객체인지 모르지만 자신이 전송한 메시지를 잘 처리할 것이라는 것을 믿고 메시지를 전송할 수 밖에 없습니다.
구현
객체지향세계에서 내부 구조와 작동 방식을 가르키는 고유의 용어는 구현이다. 객체를 구성하지만 공용 인터페이스에 포함되지 않는 모든 것을 구현이라고 한다.
인터페이스와 구현의 분리 원칙
훌륭한 객체란 구현을 모른 채 인터페이스만 알면 쉽게 상호작용할 수 있는 객체를 의미한다. 이것은 객체를 설계 할 때 외부에 노출되는 인터페이스와 객체의 내부에 숨겨지는 구현을 명확하게 분리해서 고려해야한다는 것을 의미합니다. 이를 인터페이스와 구현의 분리 원칙 이라고 한다.
책임의 자율성이 협력의 품질을 결정한다.
- 자율적인 책임은 협력을 단순하게 만든다.
- 자율적인 책임은 외부와 내부를 명확하게 분리한다.
- 책임이 자율적일 경우 책임을 수행하는 내부적인 방법을 변경하더라도 외부에 영향을 미치지 않는다.
- 자율적인 책임은 협력의 대상을 다양하게 선택할 수 있는 유연성을 제공한다
- 객체가 수행하는 책임들이 자율적일수록 객체의 역할을 이해하기 쉬워진다.
느낀점
책은 객체지향 설계에 있어서 Interface를 어떻게 설계해야 하는지 그리고 객체가 가져야할 책임에 대해서 초보자 입장에서 알기 쉽게 설명하고 있습니다.
프로그래밍에서 어떤 객체에 어떤 책임을 지우는지에 대한 고민이 왜 생겨나게 되었는지를 알기 쉽게 설명해 줍니다. 특히 이상한나라의 엘리스 삽화를 통해서 독자로 하여금 정보를 전달했습니다.
책을 다 읽고나서는 빨리 읽을걸 이라는 생각이 들었습니다. 책에서 설명하는 객체지향 설계의 의인화나 자율성, “묻지말고 시켜라”는 체득하기 까지 많은 시간이 걸렸던 항목이었습니다. 빨리 알았다면 이 소중한 지식으로 생산성있는 코드가 탄생하지 않았을까 라는 짧은 아쉬움이 있었습니다.
'개발 > 책' 카테고리의 다른 글
| [서평] Clean Architecture (2) | 2024.12.15 |
|---|
