[객체 지향] 객체 지도

객체 지도

• 길을 찾을 때 지도를 참고하는 것이 아닌 사람에게 길을 묻고 찾을 경우, 현재의 요구만을 만족시킬 수 있다.
• 하지만 지도를 참고하여 길을 찾을 때는 현재의 목적 뿐만 아니라 다양한 목적을 위해 재사용될 수 있다.
• 객체적인 관점에서 살펴볼 때 사람에게 묻고 길을 찾는 경우는 기능 에 관련된 부분이고, 지도를 참고하여 길을 찾는 경우는 구조에 관련된 부분이다.
• 지도 은유의 핵심은 기능이 아니라 구조를 기반으로 모델을 구축하는 편이 좀 더 범용적이고 이해하기 쉬우며 변경에 안정적이라는 것이다.

 

• 객체지향 개발 방법은 안정적인 구조(지도)에서 변경이 빈번하게 발생하는 기능(사람이 원하는 위치)을 종속시키는 지도의 방법과 유사하다.
  • 일반적으로 사람은 지도를 보고 자신이 가고 싶어하는 위치를 찾되, 가고 싶어하는 위치는 자주 변한다.
  • 이런 경우로 인해 객체지향은 범용적이고, 재사용성이 높으며, 변경에 안정적인 것이다.
  • 결과적으로, 객체지향은 자주 변경되는 기능이 아니라 안정적인 구조를 기반으로 시스템을 구조화한다.

 

안정적인 구조를 따라 역할, 책임, 협력을 구성하라

 

 

기능 설계 대 구조 설계

• 모든 소프트웨어 제품의 설계에는 두 가지 측면이 존재한다. 하나는 기능 측면의 설계 이고, 하나는 구조 측면의 설계이다.
  • 기능 측면 설계 : 제품이 사용자를 위해 무엇을 할 수 있는지에 초첨을 맞춘다.
  • 구조 측면 설계 : 제품의 형태가 어떠해야 하는지에 초점을 맞춘다.
  • 설계의 가장 큰 도전은 기능과 구조라는 두 가지 측면을 함께 녹여 조화를 이루도록 만드는 것이다.
• 객체지향 접근 방법은 안정적인 객체 구조를 바탕으로 시스템 기능을 객체 간의 책임으로 분배한다.
  • 시스템 기능은 나아가 더 작은 책임으로 분할되고 적절한 객체에게 분배되기 때문에 기능이 변경되더라도 객체 간의 구조는 그대로 유지된다.
  • 이로 인해 객체들은 책임과 역할을 식별하고 메시지를 기반으로 객체들의 협력 관계를 구축하는 것이다.

좋은 설계는 나중에라도 변경할 수 있는 여지를 남겨 놓는 설계이다. 즉, 안정적인 구조를 중심으로 설계하는 것이다.

 

 

두 가지 재료: 기능과 구조

• 객체지향 세계를 구축하기 위해서는 사용자에게 재공할 '기능'과 기능을 담을 안정적인 '구조'라는 재료가 준비돼 있어야 한다.

• 구조는 시스템의 기능을 구현하기 위한 기반으로, 기능 변경을 수용할 수 있도록 안정적이어야 한다.

• 기능과 구조를 표현하기 위해 일관되게 적용할 수 있는 기법.

  • 구조는 사용자나 이해관계자들이 도메인에 관해 생각하는 개념 과 개념들 간의 관계로 표현한다.
  • 기능은 사용자의 목표를 만족시키기 위해 책임을 수행하는 시스템의 행위로 표현한다.
  • 일반적으로, 기능을 수집하고 표현하기 위한 기법을 '유스케이스 모델링' 이라고 하고, 구조를 수집하고 표현하기 위한 기법을 '도메인 모델링'이라고 한다.

 

안정적인 재료: 구조

도메인 모델

• 사용자가 프로그램을 사용하는 대상 분야를 도메인이라고 한다.
  • 게임, 자산 관리 프로그램 등
• 도메인 모델이란, 사용자가 프로그램을 사용하는 대상 영역에 관한 지식을 선택적으로 단순화하고 의식적으로 구조화한 형태이다.
  • 소프트웨어가 목적하는 영역 내의 개념과 개념간의 관계, 다양한 규칙이나 제약 등을 주의 깊게 추상화한 것이다.
  • Ex. 은행에 종사하는 사람들은 은행 도메인을 고객과 계좌 사이의 돈의 흐름으로 이해할 것이다.
  • Ex. 중고차 판매상은 구매되는 자동차와 판매되는 자동차의 교환으로 자동차 도메인을 바라볼 것이다.
• 도메인 모델은 단순한 다이어그램이 아니다. 도메인 모델은 이해관계자들이 바라보는 멘탈 모델이다.
  • 멘탈 모델이란, 사람들이 자기 자신, 다른 사람, 환경, 자신이 상호작용하는 사물들에 대해 갖는 모형이다.
• 도메인 모델은 도메인에 대해 사용자 모델, 디자인 모델, 시스템 이미지를 포괄적으로 추상화한 소프트웨어 모델이다.

 

 

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

• 객체지향을 사용하면 사용자들이 이해하고 있는 도메인의 구조(사용자 모델, 디자인 모델, 시스템 이미지)와 최대한 유사하게 코드를 구조화할 수 있다.

 

표현적 차이

• 소프트웨어 객체는 현실 객체에 대한 추상화가 아니다. 소프트웨어 객체와 현실 객체 사이의 관계를 가장 잘 표현하는 키워드는 은유이다.

  • 소프트웨어 객체는 현실 객체를 모방한 것이 아니라 은유를 기반으로 재창조한 것이다.

• 현실 객체를 은유하면서 재창조한 세계는 현실에서는 존재할 수 없는 가상의 세계도 존재하게 만들었다.

  • Ex. 게임의 세계
  • 이로 인해 소프트웨어 입장에서 보면 현실 객체를 은유한다라는 말보다는 도메인 모델을 은유했다라는 말이 더 와닿을 것이다.
  • 즉, 소프트웨어 객체를 창조하기 위해 우리가 은유해야 하는 대상은 바로 도메인 모델이다.

• 소프트웨어 객체는 그 대상이 현실인지 아닌지에 상관없이 도메인 모델을 통해 표현되는 도메인 객체들을 은유해야 한다.

  • 도메인 모델을 기반으로 설계하고 구현하는 것은 사용자가 도메인을 바라보는 관점을 그대로 코드에 반영할 수 있다.
  • 
    • 코드의 구조가 도메인의 구조를 반영하기 때문에 도메인을 이해하면 코드를 이해하기가 훨씬 수월해진다.
    • 도메인 속의 개념과 관계가 코드 속에 녹아있기 때문에 도메인이 알려주는 길을 따라가면 코드 속에서 길을 잃지 않을 수 있다.

 

 

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

• 도메인 모델을 기반으로 코드를 작성하는 또 다른 이유는 도메인 모델이 제공하는 구조가 상대적으로 안정적이기 때문이다.
• 도메인 모델은 소프트웨어 구조의 기반을 이룬다. 그리고 안정적인 구조를 기반으로 자주 변경되는 기능을 배치함으로써 기능의 변경에 대해 안정적인 소프트웨어를 구현할 수 있다.
  • 이것은 도메인 모델이 기능을 담을 수 있는 안정적인 구조를 제공할 수 있음을 의미한다.
• 결과적으로 안정적인 구조를 제공하는 도메인 모델을 기반으로 소프트웨어의 구조를 설계하면 변경에 유연하게 대응할 수 있는 탄력적인 소프트웨어를 만들 수 있다.

 

불안정한 재료: 기능

유스케이스

• 소프트웨어 존재 이유는 사용자가 원하는 목표를 달성할 수 있는 다양한 기능을 제공하는 것이다. 따라서, 사용자에게 제공할 기능을 기술한 정보가 필요하고, 우리는 유스케이스라는 유용한 기법을 사용해왔다.
• 사용자의 목표를 달성하기 위해 사용자와 시스템 간에 이뤄지는 상호작용의 흐름을 텍스트로 정리한 것을 유스케이스라고 한다.
• 간단한 유스케이스를 확인해보자
  • 
    • 해당 유스케이스의 예는 중도해지 이자액을 계산한 것이다.

 

 

유스케이스의 특성

• 위 그림(중도해지 이자액)은 유스케이스의 몇가지 중요한 특성을 잘 보여준다.
  1. 유스케이스는 사용자와 시스템 간의 상호작용을 보여주는 '텍스트'이다.
     • 유스케이스는 다이어그램이 아니다.
  2. 유스케이스는 하나의 시나리오가 아니라 여러 시나리오들의 집합이다.
     • 위 그림(중도해지 이자액)은 예금주가 계좌를 선택하고 당일까지의 이자액을 계산한다 의 시나리오와 예금주가 계좌를 선택하고 특정 일자까지의 이자액을 계산한다의 사나리오의 집합을 나타낸 것이다.
  3. 유스케이스는 단순한 피처 목록과 다르다.
     • 피처는 시스템이 수행해야하는 기능의 목록을 단순하게 나열한 것이다.
     • 유스케이스는 단순히 기능을 나열하는 것이 아니라 이야기를 통해 연관된 기능들을 함께 묶을 수 있다는 점이다.
  4. 유스케이스는 사용자 인터페이스와 관련된 세부 정보를 포함하지 말아야한다.
     • 유스케이스는 자주 변경되는 사용자 인터페이스 요소는 배제하고 사용자 관점에서 시스템의 행위에 초점을 맞춘다.
  5. 유스케이스는 내부 설계와 관련된 정보를 포함하지 않는다.
     • 유스케이스의 목적은 연관된 시스템의 기능을 이야기 형식으로 모으는 것이지 내부 설계를 설명하는 것이 아니다.

 

 

유스케이스는 설계 기법도 그리고 객체지향 기법도 아니다.

• 유스케이스는 단지 사용자가 바라보는 시스템의 외부 관점만을 표현한다는 점에 주목하라.
• 유스케이스는 단지 사용자가 시스템을 통해 무엇을 얻을 수 있고 어떻게 상호작용할 수 있느냐에 관한 정보만 기술된다.
• 유스케이스 안에는 도메인 모델을 구축할 수 있는 약간의 힌트를 제공하는 것 뿐이다.

 

 

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

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

• 불안정한 기능을 안정적인 구조 안에 담음으로써, 변경에 대한 파급효과를 최소화하는 것은 훌륭한 객체지향 설계자가 갖춰야할 기본적인 설계 능력이다.

 

• 도메인 모델
  • 안정적인 구조를 개념화 하기 위해 사용되는 도구.
• 유스케이스
  • 불안정한 기능을 서술하기 위해 사용되는 도구
• 변경에 유연한 소프트웨어를 만들기 위해서는 유스케이스에 정리된 시스템의 기능을 도메인 모델을 기반으로 한 객체들의 책임으로 분배해야 한다.

 

• 책임-주도 설계
  • 유스케이스로부터 첫번째 메시지와 사용자가 달성하려는 목표를, 도메인 모델로부터 기능을 수용할 수 있는 안정적인 구조를 제공받는다.
  • 실제로 동작하는 객체들의 협력 공동체를 창조한다.
• 책임-주도 설계 방법은 시스템의 기능을 역할과 책임을 수행하는 객체들의 협력 관계로 바라보게 함으로써 두 가지 기본 재료인 유스케이스와 도메인 모델을 통합한다.

 

• 협력의 출발을 장식하는 첫 메시지는 시스템 기능을 시스템의 책임으로 바꾼 후 얻어지는 것이다.
  •  
    • 시스템에 할당된 커다란 책임은 이제 시스템 안의 작은 규모의 객체들이 수행해야 하는 더 작은 규모의 책임으로 세분화 한다. 이 때, 어떤 객체를 선택할 것인가? 이 시점에서 도메인 모델이 무대에 등장한다.
      1. 우리는 도메인 모델에 포함된 개념을 은유하는 소프트웨어 객체를 선택해야한다.
      2. 그 후, 협력을 완성하는데 필요한 메시지를 식별하면서 객체들에게 책임을 할당해 나간다.
      3. 마지막으로 협력에 참여하는 객체를 구현하기 위해 클래스, 속성, 메소드를 구현하면 시스템의 기능이 완성된다.
    • 결과적으로, 위 코드는 이제 불안정한 기능을 수용할 수 있는 안정적인 구조에 기반한 것이다.

 

 

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

• 도메인을 구성하는 기본적인 개념과 관계를 포함하는 도메인 모델을 기반으로 시스템의 기능을 대응시키니, 기능이 변경이 되도 구조는 그대로 유지된다.
• 객체지향의 가장 큰 장점은 도메인을 모델링하기 위한 기법과 도메인을 프로그래밍하기 위해 사용하는 기법이 동일하다는 점이다.