개발 다이어리

역할

책임의 집합이 의미하는 것

어떤 객체가 수행하는 책임의 집합은 객체가 협력 안에서 수행하는 역할을 암시한다.

역할은 재사용 가능하고 유연한 객체지향 설계를 낳는 매우 중요한 구성요소다.

재사용 관점을 중심 예시

김 의사가 진료를 하다, 박 의사와 교대를 해도 의사 역할 수행에는 문제가 없다.

즉, 역할 관점에서는 변화된 것이 하나도 없다.(인터페이스라 생각해보자)

역할이 답이다

역할을 사용하면 하나의 협력으로 추상화할 수 있다.

역할은 협력 내에서 다른 객체로 대체할 수 있다

단, 역할을 대체할 수 있는 객체는 동일한 메시지를 이해할 수 있는 객체로 한정 된다.

메시지는 책임을 의미한다.

동일한 역할을 수행한다는 것은 협력 내에서 동일한 책임의 집합을 수행한다는 것이다.

이 부분은 객체지향에서 매우 중요한 개념이다.

역할의 개념을 사용하면 유사한 협력을 추상화해서 인지 과부하를 줄일 수 있다.

다양한 객체들이 동일한 협력에 참여할 수 있기 때문에 재사용성이 높아진다.

역할은 객체지향 설계의 단순성(simplicity), 유연성(flexibility), 재사용성(resuability)을 뒷받침하는 핵심 개념이다.

협력의 추상화

역할의 큰 가치는 협력을 추상화할 수 있다는 것이다.

협력의 개수를 줄여 보다 추상적인 역할로 단순화해 이해하기 쉬워진다.

협력의 추상화는 근본적으로 역할의 대체 가능성에서 비롯된다.

대체 가능성

객체가 역할에 주어진 책임 이외에 다른 책임을 수행할 수도 있다.

증인 역할에 모자장수는 추가 책임으로 모자 판매를

요리사도 추가 책임으로 요리를 한다.

객체는 역할이 암시하는 책임보다 더 많은 책임을 가질 수 있다.

따라서 대부분의 경우 객체의 타입과 역할 사이에는 일반화/특수화(추상화/구체화) 관계가 성립한다.

역할의 대체 가능성은 행위 호환성을 의미한다.

행위 호환성은 동일한 책임의 수행을 의미한다.

객체의 모양을 결정하는 협력

흔한 오류

데이터를 저장하기 위해 객체가 존재한다는 선입견

데이터는 객체가 행동(책임)을 수행하는 데 필요한 재료일 뿐이다.

객체지향이 클래스와 클래스 간의 관계를 표현하는 정적인 측면에 중점을 둔다는 오류

중요한 것은 협력에 참여하는 동적인 객체이다.

클래스는 단지 객체를 표현하고 생성하기 위한 프로그래밍 매커니즘이다.(실제로 클래스가 없는 객체지향 언어 자바스크립트)

데이터나 클래스 중심으로 애플리케이션을 설계하는 오류

협력이라는 문맥을 고려하지 않고 각 객체를 독립적으로 보면 안된다.

협력을 따라 흐르는 객체의 책임

협력이라는 문맥 속에서 객체가 수행하게 될 책임(행동)결정

이후 필요한 데이터를 고민

데이터와 행동이 결정된 후 클래스 구현 방법 결정(책임 할당)

클래스와 데이터는 협력과 책임의 집합이 결정된 후 고려

객체지향 설계 기법

역할, 책임, 협력의 관점에서 애플리케이션 설계하는 유용한 세 가지 기법

책임 주도 설계(Responseibility-Driven Design) 방법

협력에 필요한 책임들을 식별, 적합한 객체에게 책임을 할당하는 방식으로 애플리케이션 설계

디자인 패턴(Design Pattern)

전문가들이 반복적으로 사용하는 해결 방법을 정의해 놓은 설계 템플릿의 모음

특정 문제를 해결하기 위해 이미 식별해 놓은 역할, 책임, 협력의 모음

베스트 프렉티스

테스트 주도 개발(Test-Driven Development)

테스트를 먼저 작성하고 테스트를 통과하는 구체적인 코드를 추가하면서 애플리케이션을 완성해가는 방식

책임-주도 설계

객체지향 시스템은 역할과 책임을 수행하는 자율적인 객체들의 공동체다.

레베카 워프스브록-책임주도설계 방법을 말한다.

시스템의 기능은 더 작은 규모의 책임으로 분할

각 책임은 책임을 수행할 적절한 객체에게 할당

이제 객체가 책임을 수행하는 도중 스스로 처리 못할 시 적절한 객체를 찾아 필요한 작업 요청(협력)

디자인 패턴

책임 주도 설계는 객체의 역할, 책임, 협력을 고안하기 위한 방법과 절차를 제시한다.

반면 디자인 패턴은 책임-주도 설계의 결과를 표현한다.

모범이 되는 설계

앨리스터 코오번에 따르면 효과적으로 일하는 사람들의 한 가지 특징은 아무것도 없는 상태에서 작업을 시작하지 않고 이전의 훌륭한 결과물을 모방하고 약간의 수정을 거쳐 원하는 결과물을 만들어 낸다는 것이다.

패턴은 특정한 상황에서 설계를 돕기 위해 모방하고 수정할 수 있는 과거의 설계 경험이다.

디자인 패턴은 반복적으로 발생하는 문제와 그 문제에 대한 해법의 쌍으로 정의된다.

해결하려고하는 문제가 무엇인지 서술하고, 패턴을 적용할 수 있는 상황과 없는 상황을 함께 설명한다.

패턴은 반복해서 일어나는 특정한 상황에서 어떤 설계가 왜(why) 더 효과적인지에 대한 이유를 설명한다.

테스트-주도 개발

애자일 방법론의 한 종류인 XP의 기본 프랙티스로 소개되며 주목받음

기본 흐름은 실패하는 테스트를 작성하거, 테스트를 통과하는 가장 간단한 코드를 작성한 후 (이 과정에서 중복은 허용된다) 리팩터링을 통해 중복을 제거하는 것이다.

테스트-주도 개발을 통해 '작동하는 깔끔한 코드'를 얻을 수 있다.

테스트 주고 개발이 응집도 높고 결합도 낮은 클래스로 구성된 시스템을 개발할 수 있게 하는 최상의 프랙티스이지만 객체지향 초보에게는 테스트를 어떤 식으로 작성해야하는지 결정하는데 어렵다.

테스트-주도 개발은 다양한 설계 경험과 패턴에 대한 지식이 없는 사람들의 경우에는 온전한 혜택을 누리기가 어렵다.

객체지향에 대한 깊이 있는 지식을 요구한다.

객체지향에 갓입문한 사람들의 가장 흔한 실수는 협력이라는 문맥을 고려하지 않은 채 객체가 가져야할 상태와 행동부터 고민하기 시작한다는 것

중요한 것은 개별 객체가 아니라 객체들 사이에 이뤄지는 협력이다.

객체지향 설계의 품질을 결정하는 것은 개별 객체의 품질이 아닌 객체들 간 협력의 품질이다.

협력은 행동으로만 이뤄진다.

객체들을 따로따로 봤을 때 이상하더라도 객체들 간 적극적인 상호작용이 중요하다.

어떤 협력에 참여하나가 객체에 필요한 행동을 결정

필요한 행동이 객체의 상태를 결정한다.

협력

요청하고 응답하며 협력하는 사람들

일반적으로 혼자만의 힘으로는 해결하기 어려운 것이 많다.

이것이 협력의 중요성

협력은 다수의 연쇄적인 요청과 응답의 흐름으로 구성된다.

앨리스 이야기 예시

재판 속의 협력

요청과 응답의 관점에서 왕이 모자 장수로부터 증언을 듣는 과정

• 누군가가 왕에게 재판을 요청함으로씨 재판이 시작된다.
• 왕이 하안 토끼에게 증인을 부를 것을 요청한다.
• 왕의 요청을 받은 토끼는 모자 장수에게 증인석으로 입장할 것을 요청한다.
• 모자 장수는 증인석에 입장함으로써 토끼의 요청에 응답한다.
• 모자 장수의 입장은 왕이 토끼에게 요청했던 증인 호출에 대한 응답이기도 하다.
• 이제 왕은 모자 장수에게 증언할 것을 요청한다.
• 모자 장수는 자신이 알고 있는 내용을 증언함으로써 왕의 요청에 응답한다.

어떤 등장인물들이 특정한 요청을 받아들일 수 있는 이유는 그 요청에 대해 적절한 방식으로 응답하는 데 필요한 지식과 행동 방식을 가지고 있기 때문이다.

요청과 응답은 협력에 참여하는 객체가 수행할 책임을 정의한다.

책임

객체가 받은 요청에 적절한 행동을 할 의무가 있는 경우 해당 객체가 책임을 가진다.

어떤 대상에 대한 요청은 그 대상이 요청을 처리할 책임이 있음을 암시하는 것

책임의 분류

책임은 객체에 의해 정의되는 응집도 있는 행위의 집합

객체의 책임은 객체가 무엇을 알고 있는가(knowing)와 무엇을 할 수 있는가(doing) 두 가지로 분류된다.

크레이그 라만의 분류법

하는 것

• 객체를 생성하거나 계산을 하는 등의 스스로 하는 것
• 다른 객체의 행동을 시작시키는 것
• 다른 객체의 활동을 제어하고 조절하는 것

아는 것

• 개인적인 정보에 관해 아는 것
• 관련된 객체에 관해 아는 것
• 자신이 유도하거나 계산할 수 있는 것에 관해 아는 것

책임은 객체지향 설계의 품질을 결정하는 가장 중요한 요소

적절한 객체에게 적절한 책임을 할당, 책임이 불분명한 객체는 안된다.

외부에서 접근 가능한 공용 서비스의 관점에서 책임

책임은 객체의 외부에 제공해 줄 수 있는 정보(아는 것)

외부에 제공해 줄 수 있는 서비스(하는 것) 의 목록이다.

따라서 책임은 객체의 공용 인터페이스를 구성한다.

책임과 메시지

객체가 다른 객체에게 주어진 책임을 수행하도록 요청을 보내는 것을 메시지 전송이라한다.

메시지는 객체 간 협력을 위한 유일한 방법이다.

책임은 협력이라는 문맥 속에서 한 쪽 객체 관점에서 무엇을 할 수 있는지를 나열하는 것이라면 메시지는 협력에 참여하는 두 객체 사이의 관계를 강조한 것이다.

책임과 메시지 수준이 같지는 않다

책임은 객체가 협력에 참여하기 위해 수행해야 하는 행위를 상위 수준에서 개략적으로 서술한 것이다.

따라서 책임을 결정한 후 실제로 협력을 정제하면서 이를 메시지로 변환할 때는 하나의 책임이 여러 메시지로 분할되는 것이 일반적이다.

객체지향이란 실세계를 직접적이고 직관적으로 모델링할 수 있는 패러다임

현실 속 존재하는 사물을 최대한 유사하게 모방해 소프트웨어 내부로 옮겨오는 작업

이과정에서 객체란 현실 세계에 존재하는 사물에 대한 추상화라는 것

위 설명은 객체지향의 기반을 이루는 철학적인 개념을 설명하는 데는 적합하지만

유연하고 실용적인 관점에선 적합하지 않다.

완벽히 일치하는 경우가 거의 없기 때문이다. 예를 들어 소프트웨어 방화벽이 건물의 방화벽과  얼마나 유사하나?

협력하는 사람들

커피 공화국의 아침

역할, 책임, 협력은 우리가 삶을 영위하기 위해 다른 사람과 접촉하는 모든 곳에 존재한다.

각각 맡은 역할을 수행하기 위해 협력하는 과정에서 책임을 다한다.

하나의 커피를 주문하는 과정을 예를 들어보자

손님, 캐시어, 바리스타는 각각의 역할이 있다. 손님은 커피를 주문하는 역할, 캐시어는 커피를 주문받는 역할, 바리스타는 커피를 제조하는 역할이 있다. 위 역할을 책임있게 수행하는 과정에서 암묵적인 협력관계가 있다.

커피 주문이라는 협력에 참여하는 모든 사람들은 커피가 정확하게 주문되고 주문된 커피가 손님에게 정확하게 전달될 수 있도록 맡은 바 역할과 책임을 다하고 있는 것이다.

요청과 응답으로 구성된 협력

일상에서 발생하는 대부분의 문제는 개인 혼자만의 힘으로 해결하기 버거울 정도로 복잡하다.

때문에 사람들은 스스로 해결하지 못하는 문제와 마주치면 문제 해결에 필요한 지식을 알고 있거나 서비스를 제공해줄 수 있는 사람에게 도움을 요청(Request)한다.

일반적으로 하나의 문제를 해결하기 위해 다수의 사람 혹은 역할이 필요

때문에대한 요청이 또 다른 사람에 대한 요청을 유발하는 것이 일반적이다.

따라서 요청은 연쇄적으로 발생한다.(협력이라 표현)

요청을 받은 사람은 주어진 책임을 다하면서 필요한 지식이나 서비스를 제공

즉, 다른 사람의 요청에 응답을 한다.

요청은 연쇄적으로 발생하므로 응답 역시 연쇄적으로 전달된다.

요청과 응답을 통해 다른 사람과 협력할 수 있는 능력은 거대하고 복잡한 문제를 해결할 수 있는 공동체를 형성할 수 있게 만든다.

협력의 성공은 특정한 역할을 맡은 각 개인이 얼마나 요청을 성실히 이행하는가에 달려 있다.

역할과 책임

사람들은 다른 사람과 협력하는 과정 속에서 특정한 역할(role)을 부여받는다.

역할은 어떤 협력에 참여하는 특정한 사람이 협력 안에서 차지하는 책임이나 임무를 의미한다.

역할은 책임이라는 개념을 내포한다.

선생님 역할은 학생을 가르칠 책임이 있음을 암시한다.

경찰관 역할은 범죄자를 잡을 책임이 있음을 암시한다.

특정한 역할은 특정한 책임을 암시한다.

사람들이 협력을 위해 특정한 역할을 맡고 역할에 적합한 책임을 수행한다는 사실은 몇 가지 중요한 개념을 제시한다.

여러 사람이 동일한 역할을 수행할 수 있다.

손님 입장에서 자신이 주문한 커피를 마실 수만 있다면 어떤 캐시어가 주문을 받는지 중요치 않다.

역할은 대체 가능성을 의미한다.

손님 입장에서 캐시어는 대체가능하다.(substitutable)

좀 더 정확히는 두명이 동일한 역할을 수행할 수 있다면 요청자 입장에서 둘 중 어떤 사람이 역할을 수행하더라도 문제가 되지 않는다.

책임을 수행하는 방법은 자율적으로 선택할 수 있다.

커피 제조를 요청받은 바리스타는 자신만의 독특한 방법으로 커피를 제조할 수 있다.

중요한 것은 커피를 제조하라는 동일한 요청을 받더라도 바리스타의 역할을 수행하는 사람들마다 서로 다른 방식으로 요청을 처리할 수 있다는 것이다.

이처럼 동일한 요청에 대해 서로 다른 방식으로 응답할 수 있는 능력을 다형성이라고 한다.

한 사람이 동시에 여러 역할을 수행할 수 있다.

캐시어와 바리스타라는 개별적인 역할을 이용해 협력 관계를 묘사했지만

한 사람이 캐시어와 바리스타의 역할을 동시에 수행하는 것도 가능하다.

따라서 한 사람이 동시에 둘 이상의 역할을 수행하는 것도 가능하다.

한 남자가 있다. 이 남자의 역할은 남편, 아이의 아버지, 직장인...

역할, 책임, 협력

기능을 구현하기 위해 협력하는 객체들

실세계의 커피를 주문하는 과정은 객체지향의 핵심적으로 중요한 개념을 거의 대부분 포함하고 있다.

사람을 객체로 , 에이전트의 요청을 메시지로, 에이전트가 요청을 처리하는 방법을 메서드로

바꾸면 대부분의 설명을 객체지향이라는 문맥으로 옮겨올 수 있다.

이제 커피 주문으로 알아본 역할, 책임, 협력의 개념을 객체지향 문맥으로 옮겨 보자

역할과 책임을 수행하며 협력하는 객체들

협력의 핵심은 특정한 책임을 수행하는 역할들 간의 연쇄적인 요청과 응답을 통해 목표를 달성한다는 것

일상생활에서 목표는 사람들의 협력을 통해 달성되며, 목표는 더 작은 책임으로 분할되고 책임을 수행할 수 있는 적절한 역할을 가진 사람에 의해 수행된다.

협력에 참여하는 각 개인은 책임을 수행하기 위해 다른 사람에게 도움을 요청하기도 하며, 이를 통해 연쇄적인 요청과 응답으로 구성되는 협력 관계가 완성된다.

객체도 이런 인간 세계와 유사하다.

애플리케이션의 기능은 더 작은 책임으로 분할되고 책임은 적절한 역할을 수행할 수 있는 객체에 의해 수행된다.

객체는 자신의 책임을 수행하는 도중 다른 객체에게 도움을 요청하기도 한다.

시스템은 역할과 책임을 수행하는 객체로 분할되고 시스템의 기능은 객체 간에 연쇄적인 요청과 응답의 흐름으로 구성된 협력으로 구현된다.

객체지향 설계는 적절한 객체에게 적절한 책임을 할당하는 것에서 시작된다.

책임이 불분명한 객체는 애플리케이션의 미래 역시 불분명하게 만든다.

역할은 관련성 높은 책임의 집합이다.

역할은 유연하고 재사용 가능한 협력 관계를 구축하는데 중요한 설계 요소다.

대체 가능한 역할과 책임은 객체지향 패러다임의 중요한 기반을 제공하는 다형성과도 깊이 연관돼있다.