개발 다이어리

마틴 파울러는 UML Distilled에서 객체지향 설계 안에 존재하는 세 가지 상호 연관된 관점에 관해 설명한다.

개념 관점, 명세 관점, 구현 관점

개념관점(Conceptual Perspective)에서 설계는 도메인 안에 존재하는 개념과 개념들 사이의 관계를 표현

도메인이란 사용자들이 관심을 가지고 있는 특정 분야나 주제를 말한다.

소프트웨어는 도메인에 존재하는 문제를 해결하기 위해 개발된다.

개념 관점은 사용자가 도메인을 바라보는 관점을 반영한다

명세 관점(Specification Perspective)에 이르면 사용자 영역인 도메인을 벗어나 개발자의 영역인 소프트웨어로 초점이 옮겨진다.

소프트웨어 안에 살아 숨쉬는 객체들의 책임에 초점(객체의 인터페이스)

객체가 협력을 위해 '무엇'을 할 수 있는가에 초점

인터페이스와 구현을 철저히 분리

구현 관점(Implementation Perspective) 실제 작업을 수행하는 코드와 연관

즉, 객체들이 책임을 수행하는 메서드를 작성

여기서는 '어떻게' 수행할지 초점

인터페이스 구현할 속성, 클래스, 메서드를 추가

위 세 가지 관점은 순서대로 진행이 아닌 세 가지 관점에서 바라보는 것이다.

클래스는 세 가지 관점을 모두 수용할 수 있도록 개념, 인터페이스, 구현을 함께 드러내야 한다.

코드 안에서 세 가지 관점을 쉽게 식별할 수 있도록 깔끔하게 분리해야 한다.

협력 안에서 메시지를 선택하고 메시지를 수신할 객체를 선택하는 것은 객체의 인터페이스, 즉 명세 관점에서 객체를 바라보는 것

코드와 세 가지 관점

코드는 세 가지 관점을 모두 제공해야 한다

개념의관점에서 코드

소프트웨어 클래스가 도메인 개념의 특성을 최대한 수용하면 변경을 관리하기 쉽고 유지보수성을 향상시킬 수 있다.

소프트웨어 클래스와 도메인 클래스 사이의 간격이 좁으면 좁을수록 기능을 변경하기 위해 뒤적거려야 하는 코드의 양도 점점 줄어든다.

명세 관점은 클래스의 인터페이스를 바라본다.

공용(public)인터페이스만이 외부 객체가 해당 객체에 접근할 수 있는 유일한 부분

객체의 인터페이스는 수정하기 어렵다. 최대한 변화에 안정적인 인터페이스를 만들기 위해 구현과 관련된 세부사항을 캡슐화한다.

구현 관점은 클래스의 내부 구현을 바라본다.

클래스의 메서드와 속성은 구현에 속하며 공용 인터페이스의 일부가 아니다. 따라서 메서드와 속성의 변경은 원칙적으로 외부에 영향을 미쳐선 안된다. 다만, 100% 막는 것은 현실적으로 힘들다.

이 말은 철저한 캡슐화를 해야한다는 것이다.

훌륭한 객체지향 프로그래머는 하나의 클래스 안에 세 가지 관점을 모두 포함하면서도 각 관점에 대응되는 요소를 명확하고 깔끔하게 드러낼 수 있다.

도메인 개념을 참조하는 이유

도메인 개념 안에서 적절한 객체를 선택하는 것은 도메인에 대한 지식을 기반으로 코드의 구조와 의미를 쉽게 유추할 수 있게 한다.

이것은 시스템의 유지보수성에 커다란 영향을 미친다.

소프트웨어는 항상 변한다. 설계는 변경을 위해 존재한다.

여러 개의 클래스로 기능을 분할하고 클래스 안에서 인터페이스와 구현을 분리하는 이유는 변경에 유연하게 대처하기 위함이다.

인터페이스와 구현을 분리하라

명세 관점과 구현 관점이 뒤섞이면 안된다.

명세 관점은 클래스의 안정적인 측면을

구현 관점은 클래스의 불안정한 측면을 드러낸다.

불안정한 재료 : 기능

유스케이스

기능적 요구사항이란 시스템이 사용자에게 제공해야 하는 기능의 목록을 정리한 것

사용자가 기능을 요구하는 이유는 목적을 달성하기 위함

사용자는 목적달성을 위해 시스템과 상호작용하는 흐름을 텍스트로 정리한 것을 유스케이스라 한다

유즈케이스는 시스템의 이해관계자들 간의 계약을 행위 중심으로 파악한다. 유스케이스는 이해관계자들 중에서 일차 액터라 불리는 행위자의 요청에 대한 시스템의 응답으로서, 다양한 조건하에 있는 시스템의 행위를 서술한다.

'일차 액터(primary actor)'란 시스템의 서비스 중 하나를 요청하는 이해관계자로 하나의 목표를 가지고 유스케이스를 시작하는 액터를 의미한다.

일반적으로 시스템과 연동하는 외부 시스템 역시 일차 액터의 범주에 포함시킨다.

사용자 목표가 유스케이스의 핵심이다. 유스케이스는 공통의 사용자 목표를 통해 강하게 연관된 시나리오의 집합이다. -마틴 파울러

유스케이스의 특성

첫째, 사용자와 시스템 간의 상호작용을 보여주는 '텍스트'다

유스케이스는 다이어 그램이 아니다 다이어 그램에 노력을 쏟지 말라.

중요한 것은 유스케이스에 담겨 있는 상호작용의 흐름이다

둘째, 유스케이스는 하나의 시나리오가 아닌 여러 시나리오들의 집합이다.

예시

첫번째 시나리오 예금주가 계좌를 선택하고 당일까지의 이자액을 계산

두번째 시나리오 예금주가 계좌를 선택하고 특정 일자까지의 이자액을 계산

시나리오를 유스케이스 인스턴스(use case instance)라 한다.

셋째, 유스케이스는 단순한 피처(feature)목록과 다르다.

피처는 단순한 기능을 나열한 목록

유스케이스에서 피처는 이야기를 통해 연관된 기능들을 묶어 문맥을 만든다.

넷째, 유스케이스는 사용자 인터페이스와 관련된 세부 정보를 포함하지 말아야 한다.

즉, 자주변경되는 '어떻게 구성되냐'에 대한 정보를 배제한다.

시스템의 행위에 초점을 맞춘다.

사용자 인터페이스를 배제한 유스케이스 형식을 본질적인 유스케이스(essential use case)라한다.

다섯째, 유스케이스는 내부 설계와 관련된 정보를 포함하지 않는다.

유스케이스 목적은 연관된 시스템의 기능을 이야기 형식으로 묶는 것이지 내부 설계를 설명하는 것이 아니다.

다섯 번째는 다음 단에서 자세히 설명

유스케이스는 설계 기법도, 객체지향 기법도 아니다

유즈케이스가 단지 사용자가 바라보는 시스템의 외부 관점만을 표현한다는 점에 주목

즉, 시스템 내부 구조나 실행 메커니즘 같은 세부 정보는 제공하지 않는다.

사용자가 시스템을 통해 무엇을 얻고 어떻게 상호작용하는 지만 제공한다.

유스케이스와 객체의 구조 사이에는 커다란 간격이 존재한다. 따라서 유스케이스를 객체로 변환하는 작업은 사실상 창조에 가깝다.

유즈케이스는 객체 구조나 책임에 대한 정보가 없기 때문이다.

재료 합치기: 기능과 구조의 통합

도메인 모델, 유스케이스, 그리고 책임-주도 설계

불안정한 기능을 안정적인 구조 안에 담는다.

도메인 모델은 안정적인 구조를 개념화, 유스케이스는 불안정한 기능을 서술하기 위한 보편적 도구다.

유스케이스에 정리된 시스템의 기능(책임)을 도메인 모델을 기반으로 한 객체들의 책임으로 분배

객체지향은 모든 것을 객체로 본다. 따라서 커대한 시스템 조차 하나의 객체로 본다.

그 객체 안에 더 작은 규모의 객체가 포함될 수 있다.

출발을 장식하는 첫 번째 메시지는 시스템의 기능을 시스템의 책임으로 바꾼 후 얻어진다.

시스템에 할당된 커다란 책임은 이제 시스템 안의 작은 규모의 객체들이 수행해야 하는 더 작은 규모의 책임으로 세분화된다.

도메인 모델에 포함된 개념을 은유하는 소프트웨어 객체를 선택해야 한다.

유스케이스는 사용자에게 제공할 기능을 시스템의 책임으로 보게 함으로써 객체 간의 안정적인 구조에 책임을 분배할 수 있는 출발점을 제공한다.

책임-주도 설계는 유스케이스로부터 첫 번째 메시지와 사용자가 달성하려는 목표를, 도메인 모델로부터 기능을 수용할 수 있는 안정적인 구조를 제공받아 실제로 동작하는 객체들의 협력 공동체를 창조한다.

시스템의 기능은 역할과 책임을 수행하는 객체들의 협력 관계를 통해 구현된다.

객체 이름은 도메인 모델에 포함된 개념으로부터 차용, 책임은 도메인 모델에 정의한 개념의 정의에 부합하도록 할당한다.

유스케이스에서 출발해 객체들의 협력으로 이어지는 일련의 흐름은 객체 안에 다른 객체를 포함하는 재귀적 합성이라는 객체지향의 기본 개념을 잘 보여준다.

기능 변경을 흡수하는 안정적인 구조

도메인 구조가 안정적인 이유

사용자가 생각하는 멘탈 모델을 모델링한 것이기 때문에 패러다임이 바뀌지 않는 이상 변하지 않는다.

모델링 모델을 중심으로 객체 구조를 설계하고 유스케이스의 기능을 객체의 책임으로 분배하는 기본적인 객체지향 설계 방식의 유연함을 잘 보여 준다.

비즈니스 정책이나 규칙이 크게 변경되지 않는 한 시스템의 기능이 변경되더라도 객체 간의 관계는 일정하게 유지된다.

기능적인 요구사항이 변경될 경우 책임과 객체 간의 대응 관계만 수정될 뿐이다.

객체지향의 가장 큰 장점은 도메인을 모델링하기 위한 기법과 도메인을 프로그래밍하기 위해 사용하는 기법이 동일하다는 것이다. 따라서 도메인 모델링에서 사용한 객체와 개념을 클래스와 메서드로 쉽게 변환할 수 있다.

이 같은 특성을 연결완전성이라한다.

또한 연결완전성의 역방향 역시 성립한다.

즉, 코드의 변경으로부터 도메인 모델의 변경 사항을 유추할 수 있다.

이게 대단한 이유는 객체지향 이전의 대부분의 개발 방법은 이를 대응 할 수 없었기 때문이다.

코드로의 매끄러운 흐름을 의미하는 연결완전성과 반대로 코드에서 모델로의 매끄러운 흐름을 의미하는 것을 가역성(reversibility)이라고 한다.

도메인 모델은 문서나 다이어그램이 아니다. 도메인 모델은 사람들의 머릿속에 들어있는 공유된 멘탈 모델이다.

따라서 별도의 문서나 다이어그램을 가지고 있지 않더라도 사람들의 머릿속에 유사한 모델이 공유될 수 있다면 그것으로 충분하다.

동일한 용어와 동일한 개념을 이용해 의사소통하고 코드로부터 도메인 모델을 유추할 수 있게 하는 것이 도메인 모델의 진정한 목표다.

유일하게 변하지 않는 것은 모든 것이 변한다는 사실뿐이다.  -헤라클레이토스

목적지까지 길을 찾는 두 가지 방법

사람에게 물어물어 가는 방법(기능적이고 해결책 지향적인 접근법)

재활용이 불가능하다. 목적지가 변경되면 다시 물어야된다.

지도를 이용하는 방법(구조적이고 문제 지향적인 접근법)

재활용이 쉽고 구조가 상대적으로 안정적이다.

과거의 지도를 봐도 현재에 활용 가능

목적지가 변해도 지도를 보고 경로 수정 가능

지도의 핵심은 기능이 아니라 구조를 기반으로 모델을 구축한 것이다.

사람들의 요구사항은 계속 변할 수 밖에 없기 때문에 기능을 중심으로 구조를 종속시키는 접근법은 범용적이지 않고 재사용이 불가능하며 변경에 취약하다.

기능 설계 대 구조 설계

소프트웨어 제품의 설계 두 가지

• 기능 측면은 제품이 무엇을 할 수 있는지에 초점
• 구조 측면은 제품의 형태가 어떠해야 하는지 초점

가장 베스트는 두 개의 적절한 조화

요구사항은 반드시 변경된다 따라서 변경이 쉬운 설계가 중요하다.

좋은 설계는 나중에 변경할 수 있는 여지는 남겨놓은 설계다.

설계의 일차적인 목표는 변경에 소요되는 비용을 낮추는 것이다.

전통적인 기능 중심 설계는 자주 변경되는 기능을 중심으로 하기에 변경에 취약하다.

객체지향 접근방법은 자주 변경되지 않는 객체 구조를 바탕으로 시스템 기능을 객체 간의 책임으로 분대한다.

객체지향은 객체의 구조에 집중하고 기능이 객체의 구조를 따르게 만든다.

두 가지 재료: 기능과 구조

기능은 사용자의 목적을 달성하기 위한 시스템의 서비스

구조는 시스템의 기능을 구현하기 위한 기반, 쉬운 변경 구조가 핵심

기능과 구조를 표현하기 위한 두 가지 기법

• 기능 수집하고 표현하기 좋은 기법은 유스케이스 모델링
• 구조를 수집하고 표현하기 좋은 기법은 도메인 모델링

안정적인 재료 : 구조

도메인 모델

사용자가 프로그램을 사용하는 대상 분야를 도메인이라고 한다.

도메인 모델에서 모델이란 대상을 단순화해서 표현한 것

모델은 지식을 선택적으로 단순화하고 의식적으로 구조화한 형태다.

현실 세계의 복잡성에서 중요한 문제에 집중하여 불필요한 세부사항은 정리해 필요한 지식만 재구성

모델은 복잡성을 관리하기 위한 도구

도메인 모델은 소프트웨어 개발과 관련된 이해관계자들이 도메인에 대해 생각하는 관점

예시) 은행 업무에 종사하는 사람들은 은행 도메인을 고객과 계좌 사이의 돈의 흐름으로 생각할 것

도메인 모델은 단순히 다이어그램이 아니다. 도메인 모델은 이해관계자들이 바라보는 멘탈 모델(Mental Model)이다.

멘탈 모델이란 사람들이 자기 자신, 다른 사람, 환경, 자신이 상호작용하는 사물들에 대해 갖는 모형이다.

사람들은 세상에 존재하는 현상을 이해하고 현상에 반응하기 위해 자신의 마음 속에 멘탈 모델을 구축한다.

사람들은 자신의 멘탈 모델과 유사한 방식으로 제품이 반응하고 움직일 것이라고 기대하기 때문에 훌륭한 디자인이란 사용자가 예상하는 방식에 따라 정확하게 반응하는 제품을 만드는 것이다. - 도널드 노먼

노먼의 멘탈 모델은 세 가지로 구분된다.

사용자 모델, 디자인 모델, 시스템 이미지

사용자 모델과 디자인 모델이 동일하다면 이상적이다.

사용자와 설계자는 직접적으로 상호작용할 수 없으며 단지 최종 제품인 시스템 그 자체를 통해서만 의사소통할 수 있다.

따라서 설계자는 디자인 모델을 기반으로 만든 시스템 이미지가 사용자 모델을 정확하게 반영하도록 노력해야 한다.

도메인 모델은 도메인에 대한 사용자 모델, 디자인 모델, 시스템 이미지를 포괄하도록 추상화한 소프트웨어 모델이다. 따라서 도메인 모델은 소프트웨어에 대한 멘탈 모델이다.

도메인의 모습을 담을 수 있는 객체지향

최종 코드는 사용자가 도메인을 바라보는 관점을 반영해야한다.

객체지향은 도메인의 구조와 최대한 유사하게 코드를 구조화할 수 있다.

객체지향을 이용하면 도메인에 대한 사용자 모델, 디자인 모델, 시스템 이미지 모두가 유사한 모습을 유지하도록 만드는 것이 가능하다. 이런 특징을 연결 완전성, 표현적 차이라고 한다.

표현적 차이

소프트웨어는 현실세계에 대한 추상화가 아니다.

현실과 객체 사의 관계를 은유를 기반으로 재창조한 것이다.

따라서 현실 객체가 갖지 못하는 특성과 행동을 가질 수 있다.

그것이 비록 현실을 왜곡한다고 해도 말이다.

소프트웨어 객체와 현실 객체 사이의 의미적 거리를 가리켜 표현적 차이 또는 의미적 차이라 한다.

핵심은 은유를 통해 현실 객체와 소프트웨어 객체 사이의 차이를 최대한 줄이는 것이다.

안타깝지만 대부분의 소프트웨어 도메인은 현실에 존재하지 않는 가상의 세계를 대상으로 한다.

게임 도메인을 예를 들면 아주 현실에 존재하지 않는 강력한 마법과 괴물들의 천국이다.

여기에 빗대어 보면 현실 객체를 은유하라는 말이 공허한 메아리 같다.

그렇다면 은유의 대상을 바꿔보자. 바로 사용자가 도메인에 대해 생각하는 개념으로

결론적으로 소프트웨어는 현실적이건 비현실적이건 상관없이 도메인 모델을 통해 표현되는 도메인 객체들을 은유해야 한다.

그 결과로 표현적 차이는 줄어들어 사용자의 멘탈 모델이 그대로 코드에 녹아 들 것이다.

표현적 차이가 중요한 이유는 소프트웨어를 이해하고 수정하기 쉽게 만들어 주기 때문이다.

도메인 속의 개념과 관계가 코드 속에 녹아 있기 때문이다.

불안정한 기능을 담는 안정적인 도메인 모델

도메인 모델이 제공하는 구조는 상대적으로 안정적이다.

도메인에 대한 사용자 관점을 반영해야 하는 이유는 사용자들이 누구보다도 도메인의 '본질적인' 측면을 가장 잘 이해하고 있기 때문(멘탈 모델)

본질적이라는 것은 변경이 적고 비교적 그 특성이 오랜 시간 유지된다는 것을 의미한다.

사용자 모델에 포함된 개념과 규칙은 비교적 변경될 확률이 적기 때문에 사용자 모델 기반으로 설계와 코드를 만들면 변경에 쉽게 대처할 수 있을 가능성이 커진다.

도메인 모델은 기능을 담을 수 있는 안정적인 구조를 제공한다.

도메인 모델은 소프트웨어 구조의 기반이다.

안정적인 구조를 바탕으로 자주 변경되는 기능을 배치해 변경에 유연하게 대처가능하다.

도메인 모델의 장점은 비즈니스의 개념과 정책을 반영하는 안정적인 구조를 제공한다는 것이다.

비록 도메인 모델이 도메인과 관련된 중요한 개념과 관계를 보여준다고 해도 실제로 사용자에게 중요한 것은 도메인 모델이 아니라 소프트웨어의 기능이다.

소프트웨어의 존재 이유는 사용자가 원하는 목표를 달성할 수 있는 다양한 기능을 제공하는 것이다.

따라서 사용자에게 제공할 기능을 기술할 정보가 필요하다. 이를 위해 유스케이스라는 기법을 사용한다.

메시지를 따라라

객체지향의 핵심, 메시지

협력을 위한 유일한 수단

클래스 간 상속관계를 핵심으로 생각하는 잘못된 관점이 존재한다. 하지만 객체지향은 '객체'지향이지 클래스 지향이 아니다. 그래서 클래스가 없는 객체지향 언어도 있다.

클래스는 동적인 객체들의 특성과 행위를 정적인 텍스트로 표현하기 위해 사용할 수 있는 추상화 도구일 뿐이다.

객체지향 설계는 메시지를 주고 받는 동적인 객체들 관점에서 설계

객체지향 설계의 중심에는 메시지가 위치

객체가 메시지를 선택하는 것이 아닌

메시지가 객체를 선택해야 한다.(적절한 객체에게 적절한 책임 분배)

책임-주도 설계 다시 살펴보기

책임을 완수하기 위해 협력하는 객체들을 이용해 시스템을 설계하는 방법을 책임-주도 설계라고 한다.

필요한 책임(행동)을 먼저 정의한다.

그리고 그 책임을 수행할 객체를 선정한다.(메시지 수신은 그 객체에게 부여된 책임)

맡은 책임을 그 객체가 수행할 수 없다면 다른 객체에게 요청을 한다.(책임 연쇄)

이를 반복한다.

What/Who 사이클

어떤 행위가 필요한지를 먼저 결정한 후 이 행위를 수행할 객체를 결정하는 것을 What/Who 사이클이라 한다.

What(행위) Who(객체)

이과정에서 상태는 중요치 않다. 즉, 어떤 객체가 특정 특성을 가졌다고 해서 반드시 그와 관련된 행위를 수행할 것이라고 가정하지 않는다.

협력이라는 문맥 안에서 객체의 책임을 결정하라.

시스템이 수행해야 하는 전체 행위는 협력하는 객체들의 책임으로 분배된다.

묻지 말고 시켜라

메시지를 먼저 결정하고 객체가 메시지를 따르게 하는 설계 방식은 객체가 외부에 제공하는 인터페이스가 독특한 스타일을 따르게 한다. 이를 Tell, Don't Ask 또는 데메테르 법칙이라 한다

메시지를 결정하는 시점에서 어떤 객체가 메시지를 수신할 것인지를 알 수 없다. 때문에 메시지 송신자는 메시지 를 수신할 객체의 내부 상태를 볼 수 없다.

이는 메시지 수신자의 캡슐화를 의미한다.

이는 느슨한 결합을 의미한다.

묻지 말고(내부 구체적인 동작방식= how) 시켜라(요청= 메시지)

객체의 자율성 증가

어떻게 해야하는지 지시하지 말고 무엇을 해야하는 지를 요청하는 것은 인터페이스 크기 감소를 가져온다.

인터페이스 크기가 작다는 것은 해당 객체에게 외부에서 의존하는 부분이 적다는 것이다

메시지를 믿어라

메시지는 전송하는 객체 관점에서 수신하는 객체가 의도한 대로 처리만 할 수 있기만 하면된다. 구체적인 방법은 중요하지 않다. 즉, 수신하는 객체가 변경되어 다른 방법을 취하더라도 처리만 되면 그만이다.

유연하고 재사용성이 높아진다.

객체 인터페이스

인터페이스

인터페이스란 어떤 두 사물이 마주치는 경계 지점에서 서로 상호작용할 수 있게 이어주는 방법이나 장치

인터페이스 세 가지 특징

첫째, 인터페이스의 사용법을 익히기만 하면 내부 구조나 동작 방식을 몰라도 쉽게 대상을 조작하거나 의사를 전달할 수 있다.

둘째, 인터페이스 자체는 변경하지 않고 단순히 내부 구성이나 작동 방식만을 변경하는 것은 인터페이스 사용자에게 어떤 영향도 미치지 않는다.

셋째, 대상이 변경되더라도 동인한 인터페이스를 제공하기만 하면 아무런 문제 없이 상호작용할 수 있다.

자동차를 운전할 때 패달, 핸들 정도만 조작할 줄 알면 된다. 엔진이 어떻게 구성되어 있는지 알필요가 있는가?

자동차 수리로 내부 부품이 변경되어도 운전하는데 문제 없다.

또한 다른 자동차로 변경되어도 운전에는 무리가 없다.

인터페이스를 통한 상호작용이 중요하다.

메시지가 인터페이스를 결정한다.

객체 간 협력을 위한 유일한 방법은 메시지

객체가 수신할 수 있는 메시지 목록이 인터페이스 모양이 된다.

공용 인터페이스

지금까지는 전부 공용 인터페이스를 기본으로 말했다.

외부에 공개된 인터페이스를 공용 인터페이스라 한다.

사적인 인터페이스도 존재한다. 다만 사적인 인터페이스는 객체 자신과의 메시지 상호작용이다.

책임, 메시지, 그리고 인터페이스

객체의 책임이 자율적이어야 한다.

객체가 수행할 구체적인 행동에 대한 자율성

메시지로 구성된 공용 인터페이스는 객체의 외부와 내부를 명확하게 분리한다.

인터페이스와 구현의 분리

객체 관점에서 생각하는 방법

맷 와이스펠드의 객체지향적인 사고 방식 이해를 위한 세 가지 원칙

좀 더 추상적인 인터페이스

객체의 구현에 대한 자율성 보장

최소 인터페이스

외부에 노출될 메서드를 최소한

의존성 저하로 결합도와 재사용성 혜택

노출 최소화로 캡슐화

인터페이스와 구현 간에 차이가 있다는 점을 인식

구현

객체지향에서 내부 구조와 작동 방식을 가리키는 용어

객체를 구성하지만 공용 인터페이스에 포함되지 않는 모든 것

인터페이스에 정의된 선언부를 제외한 모든 것

메서드 구현부, 변수

인터페이스와 구현의 분리 원칙

separation of interface and implementation

객체 외부에 노출되는 인터페이스와 객체의 내부에 숨겨지는 구현을 명확하게 분리

두 개의 분리된 요소로 분할해 설계하는 것(외부 공개 인터페이스와 내부에 감춰지는 구현)

느슨한 결합을 보장

인터페이스와 구현을 분리한다는 것은 변경될 만한 부분을 객체의 내부에 꽁꽁 숨겨 놓는다는 것을 의미 (캡슐화)

따라서 변경에 유리

캡슐화

객체의 자율성을 보존하기 위해 구현을 외부로부터 감추는 것

객체는 상태와 행위를 캡슐화함으로써 협력속에서 자율적인 존재가 될 수 있다.

캡슐화를 정보 은닉이라고 부르기도 한다.

상태와 행위의 캡슐화

객체 = 상태 + 행위

객체는 자신의 상태를 스스로 관리하며 상태를 변경하고 외부에 응답할 수 있는 행동을 내부에 함께 보관한다.

이 중에서 외부에서 반드시 접근해야만 하는 행위만 골라 공용 인터페이스를 통해 노출

전통적인 개발에서는 데이터와 프로세스를 엄격히 분리

객체지향에서는 데이터와 프로세스를 객체라는 하나의 틀 안으로 함께 묶어 객체의 자율성을 보장

사적인 비밀의 캡슐화

캡슐화를 통해 변경이 빈번하게 일어나는 불안전한 비밀을 안정적인 인터페이스 뒤로 숨긴다.

공용 인터페이스를 수정하지 않는 한 자신과 협력하는 외부 객체에 영향을 미치지 않고 내부의 구현을 자유롭게 수정할 수 있다.

이것은 인터페이스와 구현의 분리원칙과 연결된다.

구현 변경에 의한 파급효과를 최대한 억눌른다.

객체를 자율적인 존재로 만든다 = 내부와 외부를 엄격히 분리한다.

책임의 자율성이 협력의 품질을 결정한다

첫쨰, 자율적인 책임은 협력을 단순하게 만든다.

구체적인 구현을 감춤으로써 핵심만 간략히 할 수 있다.

둘째, 자율적인 책임은 모자 장수의 외부와 내부를 명확하게 분리한다.

책임만 보장하면 된다. 책임을 어떻게 수행할지는 자유이다.

사적인 부분이 캡슐화되기 때문에 인터페이스와 구현이 분리된다.

셋째, 책임이 자율적일 경우 책임을 수행하는 내부적인 방법을 변경하더라도 외부에 영향을 미치지 않는다.

요청자는 메시지 수신자에 내부를 볼 수도 알 수도 없다.

이는 변경되어도 요청자는 변경됐다는 사실조차 알 수가 없다.

결국 메서드의 결합도가 객체의 결합도에 영향을 미친다.

넷째, 자율적인 책임은 협력의 대상을 다양하게 선택할 수 있는 유연성을 제공한다.

책임이 자율적일수록 협력이 좀 더 유연해지고 다양한 문맥에서 재활용될 수 있다.

다섯째, 객체가 수행하는 책임들이 자율적일수록 객체의 역할을 이해하기 쉬워진다.

책임이 자율적일수록 적절하게 '추상화'되며, '응집도'가 높아지고, '결합도'가 낮아지며, '캡슐화'가 증진되고, '인터페이스와 구현이 명확히 분리'되며, 설계의 '유연성'과 '재사용성'이 향상된다.

의도는 "메시징"이다. 훌륭하고 성장 가능한 시스템을 만들기 위한 핵심은 모듈 내부의 속성과 행동이 어떤가보다는 모듈이 어떻게 커뮤니케이션하는가에 달려있다. -앨런 케이

자율적인 책임

설계의 품질을 좌우하는 책임

자율적인 객체란 스스로 정한 원칙에 따라 판단하고 스스로의 의지를 기반으로 행동하는 객체

적절한 책임이 자율적인 객체를 낳고, 자율적인 객체들이 모여 유연하고 단순한 협력을 낳는다.

협력에 참여하는 객체가 얼마나 자율적인지에 따라 애플리케이션 품질이 결정된다.

너무 추상적인 책임

추상적인 것도 정도가 있다. 협력의 의도를 명확하게 표현하지 못할 정도로 추상적인 것은 문제다.

추상적인 책임은 재사용성과 유연성을 가진다. 다만 협력에 참여하는 의도는 명확하게 설명할 수 있는 수준이야 한다.

'어떻게'가 아니라 '무엇'을

책임을 어떻게는 질지가 중요한게 아니라. 책임이 무엇인지가 중요하다.

어떻게는 구체적인 방법이라 객체의 행동에 자율성을 제한한다.

다형성을 떠올려보자. 무엇을 제공해주는 지가 중요하지 그 방법 따위는 중요치 않다.

이는 결국 결합도와도 연결된다. 

책임을 자극하는 메시지

객체가 자신에게 할당된 책임을 수행하도록 만드는 것은 외부에서 전달되는 요청이다.

사실 객체 간 소통은 요청뿐이다.

요청=메시지

메시지와 메서드

메시지

메시지를 전송함으로써 다른 객체에 접근한다.

메시지는 이름과 인자 두 부분으로 구성(메서드나 함수)

메시지 전송은 수신자, 메시지 이름, 인자로 구성됨

메시지 수신을 통해서만 자신의 책임을 수행할 수 있다.

메시지는 객체들이 서로 협력하기 위해 사용할 수 있는 유일한 의사소통 수단이다. 객체가 메시지를 수신할 수 있다는 것은 객체가 메시지에 해당하는 책임을 수행할 수 있다는 것을 의미한다. 객체가 유일하게 이해할 수 있는 의사소통 수단은 메시지뿐이며 객체는 메시지를 처리하기 위한 방법을 자율적으로 선택할 수 있다. 외부 객체는 메시지에 관해서만 볼 수 있고 객체 내부는 볼 수 없기 때문에 자연스럽게 객체의 외부와 내부가 분리된다.

메서드

메시지 수신을 처리하기 위해 내부적으로 선택하는 방법을 메서드라 한다.

다형성

서로 다른 유형의 객체가 동일한 메시지에 대해 서로 다르게 반응하는 것

무엇이 실행될 지는 명시했지만 어떻게 실행할 것인지는 수신자가 결정한다.

다형성을 만족시킨다는 것은 객체들이 동일한 책임을 공유한다는 것

송신자의 관점에서 다형성은 수신자들을 구분할 필요없다. 저 마다 방법이 다를지라도 다 동일한 책임을 수행하기 때문이다.

더 나아가 수신자가 무엇인지 관심도 없다. 역할만 알면된다.(대체 가능성)

따라서 유연하고 재사용성이 높아진다.

송신자-수신자 사이 객체 타입에 대한 결합도를 메시지에 대한 결합도를 낮춤으로써 달성한다.

유연하고 확장 가능하고 재사용성이 높은 협력의 의미

메시지 송신자는 수신자가 메시지를 이해할 수 있다는 사실만 알고 있는 상태에서 협력에 참여한다.

매우 작은 정보만 알고 있더라도 상호 협력이 된다는 것은 설계의 품질에 큰 영향을 미친다.

첫째, 협력이 유연해진다. 수신자가 대체 되더라도 상관이 없고, 송신자는 변경 사실을 알 수 조차 없다.

둘째, 협력이 수행되는 방식을 확장할 수 있다. 송신자에게 아무런 영향 없이 수신자를 교체할 수 있기 때문에 세부 수행 방식을 쉽게 수정할 수 있다.

셋째, 협력이 수행되는 방식을 재사용할 수 있다. 수신자가 교체가 가능하기 때문에 문맥에 맞게 재사용할 수 있다.

송신자와 수신자를 약하게 연결하는 메시지

메시지는 송신자와 수신자 사이의 결합도를 낮춤으로써 설계를 유연하고, 확장 가능하고, 재사용 가능하게 만든다.

송신자의 관점에서 송신자는 메시지만 바라본다. 수신자의 정확한 타입을 모르더라도 상관없다. 단지 잘 처리해 줄 것이라는 사실만 알면 그만이다.

수신자는 메시지를 처리할 방법을 자유롭게 선택하며, 구체적인 방법은 송신자에게 노출하지 안는다.

송신자와 수신자 사이 약하게 연결하는 메시지는 낮은 결합도를 보장한다.

이에 따라 유연하고, 대체가능하며, 재사용 가능하며, 확장까지 가능하다.

역할

책임의 집합이 의미하는 것

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

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

재사용 관점을 중심 예시

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

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

역할이 답이다

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

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

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

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

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

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

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

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

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

협력의 추상화

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

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

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

대체 가능성

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

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

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

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

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

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

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

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

흔한 오류

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

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

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

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

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

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

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

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

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

이후 필요한 데이터를 고민

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

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

객체지향 설계 기법

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

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

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

디자인 패턴(Design Pattern)

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

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

베스트 프렉티스

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

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

책임-주도 설계

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

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

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

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

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

디자인 패턴

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

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

모범이 되는 설계

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

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

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

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

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

테스트-주도 개발

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

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

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