개발 다이어리

일반화와 특수화

범주의 계층

18세기 자연에 대한 관심 증가로 매년 수천 종의 생물들이 새롭게 발견

끝임없이 쏟아져 보편적 분류 체계가 필요하다 느낌

1735년 카를로스 린네 자연의 체계를 발표

계문강목과속종

린네의 분류 체계는 범주 간의 계층적인 구조를 가짐

모든 포유류는 척추가 있고 새끼를 낳아 젖을 먹여 기른다는 특징을 공유

따라서 얼룩고양이도 척추가 있고 새끼를 낳아 기르며 젖을 먹여 새끼를 기를 것이라는 사실을 쉽게 알 수 있다.

린네의 계층 구조는 좀 더 세부적인 범주가 계층의 하위에 위치하고 좀 더 일반적인 범주가 계층의 상위에 위치한다.

계층 상위에 위치한 범주를 계층 하위에 위치한 범주의 일반화

계층의 하위에 위치한 범주는 계층의 상위에 위치한 범주의 특수화라고 한다.

서브타입

객체지향의 세게에서 범주는 개념, 개념은 타입

따라서 일반화와 특수화는 계층 구조 안에서 존재하는 타입 간의 관계를 의미한다.

어떤 타입이 다른 타입보다 일반적이라면 슈퍼 타입(supertype)

어떤 타입이 다른 타입보다 좀 더 특수하다면 서브타입(subtype)이라고 한다.

슈퍼타입은 서브타입의 일반화

서브타입은 슈퍼타입의 특수화

일반화와 특수화 계층 구조에서 서브타입은 슈퍼타입이 가진 본질적인 속성과 함께 자신만의 추가적인 속성을 가진다.

크레이그 라만은 어떤 타입이 다른 타입의 서브타입이 되기 위해서는 100% 규칙과 Is-a 규칙을 준수해야한다고 했다.

100% 규칙은 내연 관련

Is-a 규칙은 외연 관련 규칙이다.

• 100%규칙
  슈퍼타입의 정의가 서브타입에 100% 적용되어야 한다
  서브타입은 속성과 연관관계 면에서 슈퍼타입과 100% 일치해야 한다.
• Is-a 규칙(is-a-kind-of)
  서브타입의 모든 인스턴스는 슈퍼타입 집합에 포함돼야 한다.
  "서브타입은 슈퍼타입이다" 라는 말에 대입해서 맞다면 적용되는 것으로 본다.
  인간은 동물이다. (일치) / 컴퓨터는 동물이다(불일치)
  서브타입이 슈퍼타입의 부분집합인 것을 알 수 있다.

상속

일반화 특수화 관계를 구현하는 일반적인 방법은 클래스 간 상속을 사용하는 것

반드시 모든 상속 관계가 일반화 관계인 것은 아니다.

일반화의 원칙은 한 타입이 다른 타입의 서브타입이 되기 위해서는 슈퍼타입에 순응(conformance)해야 한다는 것

순응은 구조적인 순응(structural conformance)과 행위적인 순응(behavioral conformance)의 두 가지 종류가 있다.

두 가지 모두 특정 기대 집합에 대해 서브타입의 슈퍼타입에 대한 대체 가능성을 의미한다.

• 구조적인 순응의 경우 기대 집합은 속성과 연관관계에 관한 것
• 행위적인 순응의 경우 기대 집합은 행위가 동일한 계약을 기반으로 하느냐

구조적인 순응은 타입의 내연과 관련된 100% 규칙을 의미(속성)

Person 클래스에 name 속성이 있다고 가정, Person의 서브타입인 Employee 역시 name 속성을 가져야 한다.

Employee 클래스는 구조적으로 Person클래스를 대체할 수 있다.

행위적 순응은 흔히 리스코프 치환 원칙(Liskov Substitution Principle,LSP)이라고 한다.

Person.getAge()가 나이를 반환한다면 Employee.getAge()역시 나이를 반환해야 한다.

Employee는 Person에 대해 행위적으로 순응하기 때문에 대체 가능하다.

상속의 또다른 용도는 코드 중복을 방지 공통 코드를 재사용하기 위한 언어적 메커니즘을 제공하는 것

상속은 서브타이핑(subtyping)과 서브클래싱(subclassing)의 두 가지 용도로 사용될 수 있다.

• 서브 클래스가 슈퍼클래스를 대체할 수 있는 경우 이를 서브타이핑이라고 한다.
• 서브 클래스가 슈퍼클래스를 대체할 수 없는 경우 서브클래싱이라고 한다.

서브타이핑은 설계의 유연성이 목표

서브클래싱은 코드의 중복 제거와 재사용이 목적

서브타이핑은 인터페이스 상속(interface inheritance)

서브클래싱을 구현 상속(implementation inheritance)이라고 한다.

클래스가 다른 클래스를 상속받았다는 사실만으로 두 클래스 간의 관계가 서브타이핑인지, 서브클래싱인지 여부를 결정할 수 없다.

서브타이핑의 전제 조건은 대체 가능성이기 때문에 클라이언트 관점에서 실제로 어떻게 사용되고 있는지를 확인해야 한다.

가능한 모든 상속관계가 서브타이핑의 대체 가능성을 준수하도록 하는 것이 좋다

여러 클래스로 구성된 상속 계층에서 수신된 메시지를 이해하는 기본적인 방법은 클래스 간 위임(delegation)을 사용하는 것 

집합과 분해

계층적인 복잡성

복잡성은 계층의 형태를 띈다.

단순한 형태로부터 복잡한 형태로 진화하는데 걸리는 시간은 그 사이에 존재하는 안정적인 형태의 수와 분포에 의존한다

시계는 중간 부품들을 조립해서 만들어진다.

그 중간 부품은 더 작은 부품들을 조립해서 만들어진다.

결국 시계는 전체적으로 연쇄적인 계층 구조로 구성된다.

이 같이 안정적인 형태의 부분으로부터 전체를 구축하는 행위를 집합이라고 한다.

그 반대로 전체를 부분으로 분할하는 행위를 분해라고 한다.

집합의 가치는 많은 수의 사물들의 형상을 하나의 단위로 다룸으로써 복잡성을 줄일 수 있다는 데 있다.

집합은 불필요한 세부 사항을 배제하고 큰 그림에서 대상을 다룰 수 있게 한다. (추상화, 캡슐화)

그러나 필요한 시점에는 전체를 분해함으로써 그 안에 포함된 부분들을 새로운 전체로 다룰 수 있다.

합성 관계

상품 주문을 생각해보자.

상품 주문은 여러 상품을 한 번에 주문할 수 있다.

이때 각 상품을 몇 개 주문했는지를 가리켜 주문 항목이라고 한다.

주문 항목은 주문과 독립적으로 존재할 수 없다. 반드시 어느 한 주문에 주문항목이 일부로 생성되기 때문이다.

객체와 객체 사이의 전체-부분 관계를 구현하기 위해서는 합성 관계를 사용한다.

합성관계는 부분을 전체 안에 캡슐화함으로써 단순화한다.

즉, 주문과 상품만이 존재하는 것처럼 모델을 다룰 수 있다.

필요시 주문 내부의 세부적인 주문항목을 보는 것

주문항목은 주문과 전체와 부분을 나타내는 합성관계다.

주문항목과 상품 간에도 선이 연결되어 있는데 이를 연관 관계라 한다.

일반적으로 합성관계로 연결된 객체는 포함하는 객체가 제거되면 같이 제거된다.

주문이 제거되면 주문항목이 존재할 수 없으니 같이 제거

연관 관계는 주문 제거되더라도 상품은 계속 판매될 것이다.

패키지

합성 관계를 통해 단순화 하더라도 결국 클래스 수가 많아지면 복잡해진다.

서로 관련성이 높은 클래스 집합을 논리적인 단위로 통합

관련된 클래스 집합을 하나의 논리적인 단위로 묶는 구성 요소를 패키지(package)또는 모듈(module)이라한다.

합성 관계가 내부에 포함된 객체들의 존재를 감춤으로써 내부 구조를 추상화하는 것 처럼 패키지는 내부에 포함된 클래스들을 감춤으로써 시스템의 구조를 추상화한다.

추상화 기법

추상화는 도메인의 복잡성을 단순화하고 직관적인 멘탈 모델을 만드는 데 사용할 수 있는 기본적인 인지 수단이다

동일한 특성을 공유하는 객체들을 타입으로 분류하는 것이 추상화 기법의 예다.

각 추상화 기법은 결국 복잡성을 낮추기,세부사항 감추기

• 분류와 인스턴스화 
  분류는 객체의 구체적인 세부 사항을 숨김, 인스턴스 간 공유하는 공통적인 특성을 기반으로 범주화
  인스턴스화는 범주로부터 객체를 생성하는 것
• 일반화와 특수화
  범주 사이의 차이를 숨기고 번주 간에 공유하는 공통적인 특성을 강조
  이 반대가 특수화
• 집홥과 분해
  부분과 관련된 세부 사항을 숨기고 부분을 사용해서 전체를 형성하는 과정을 가리킴
  집합의 반대 과정은 전체를 부분으로 분리하는 분해

분류와 인스턴스화

개념과 범주

개념이란 속성과 행위가 유사한 객체에 공통적으로 적용되는 관념이나 아이디어다 -Martin

객체를 분류하고 범주로 묶는 것은 객체들의 특정 집합에 공통의 개념을 적용하는 것을 의미한다.

나무라는 범주에는 '푸른 잎과 갈색의 줄기를 가진 다년생 식물'이라는 개념을 적용할 수 있다.

객체들을 공통적인 특성을 기반으로 범주로 묶고, 개념을 적용하는 것은 범주라는 정신적인 렌즈를 통해 세상을 바라보는 것과 유사하다.

자동차라는 렌즈를 통해 바라본 세상은 자동차 범주에 속한 객체만 보일 것

세상에 존재하는 객체에 개념을 적용하는 과정을 분류라고 한다. -Martin

분류는 객체를 특정한 개념을 가타내는 집합의 구성 요소로 포함시킨다.

세상에 존재하는 서로 다른 상태를 가진 무수히 많은 자동차와 나무를 개별적으로 다루기는 불가능하다. 그래서 범주로 묶어 세상이 가진 복잡성을 낮춘다.

사람들은 분류를 통해 개별 현상을 하나의 개념으로 다룬다.

이때 '수많은 개별적인 현상들'을 객체라하고, '하나의 개념'을 타입이라고 한다.

분류는 객체를 타입과 연관시키는 것이다.

분류의 역은 타입에 해당하는 객체를 생성하는 과정으로 인스턴스화 또는 예시라고 한다.

객체지향 세계에서 개념을 가리키는 표준 용어는 타입이다. -Martin

객체를 타입의 인스턴스라고 한다.

분류는 객체와 타입 간의 관계를 나타낸 것이다.

어떤 객체가 타입의 정의에 부합할 경우 그 객체는 해당 타입으로 분류되며 자동으로 타입의 인스턴스가 된다.

타입

타입을 객체의 분류 장치로서 적용할 수 있으려면 다음과 같은 세 가지 관점에서의 정의가 필요하다 - Martin

• 심볼
  타입을 가리키는 간단략 명칭
• 내연
  타입의 완전한 정의
• 외연
  타입에 속하는 모든 객체들의 집합

외연과 집합

타입의 외연은 타입에 속하는 객체들의 집합으로 표현

집합 = 외연

객체들은 동시에 서로 다른 집합에 포함될 수도 있다.

한 객체가 하나의 타입에 속하는 경우 단일 분류(single classification)

여러 타입에 속하는 경우 다중 분류(multiple classification)라 한다.

대부분의 객체지향 프로그래밍 언어들은 단일 분류만을 지원한다.

대부분의 언어에서 한 객체는 오직 한 클래스의 인스턴스여야만 하며 동시에 두 개의 클래스의 인스턴스일 수는 없다. 이 관점에서 다중 분류를 다중 상속과 혼동해서는 안된다.

다중 상속은 하나의 타입이 다수의 슈퍼타입을 가질 수 있도록 허용하지만 타입 정의를 생략할 수는 없다. 반면 다중 분류는 특정한 타입을 정의하지 않고도 하나의 객체가 서로 다른 타입의 인스턴스가 되도록 허용한다.

객체를 특정한 타입으로 분류하면 해당 객체는 타입의 집합에 포함된다.

객체가 한 집합에서 다른 집합의 원소로 자신이 속하는 타입을 변경할 수 있는 경우 이를 동적 분류(dynamic classification)이라고 한다.

객체가 자신의 타입을 변경할 수 없는 경우 이를 정적 분류(static classification)라 한다.

하나의 컴퓨터가 시간의 흐름에 따라 교육용 컴퓨터에서 사무용 컴퓨터로, 다시 사무용에서 교육용 컴퓨터로 분류가 바뀌는 과정은 컴퓨터가 여러 집합에 속할 수 있다는 것

다중 분류와 동적 분류는 서로 배타적인 개념이 아니다. 함께 적용하는 것이 실세계의 복잡성을 모델링하는데 유용하다.

클래스 기반의 객체지향에서 타입은 클래스로 구현된다.

대부분의 언어는 일단 클래스로부터 인스턴스를 생성한 후 클래스를 변경할 수 있는 방법을 제공하지 않는다. 즉, 객체의 타입을 변경할 수 없다. 따라서 우리가 사용하는 대부분의 언어는 정적 분류만 허용하며 동적 분류를 구현할 수 있는 방법을 제공하지 않는다.

이처럼 언어의 제약으로 인해 다중 분류와 동적 분류를 구현으로 옮기기 쉽지 않다.

절충안으로 도메인 모델의 초안을 다중 분류와 동적 분류로 만들고, 실제 구현에 적합하도록 단일 분류와 정적 분류 방식으로 객체들의 범주를 재조정하는 것이 좋다.

디자인 템플릿은 유연성이라는 측면에서 꼭 필요한 경우에만 사용

단순함을 위해서는 단일 분류와 정적 분류를 선택

클래스

타입을 구현하는 가장 보편적인 방법

클래스는 타입 구현 용도 외에 코드 재사용 용도로 사용할 수 있다.

추상 클래스, 인터페이스도 타입 구현 가능

현재 객체지향 패러다임은 아리스토텔레스 분류법의 근간을 형성하는 아이디어를 근간으로 한다

아리스토 텔레스는 객체의 특성을 본질적인 속성과 우연적인 속성으로 분류했다.

본질(essence)이란 한 사물의 가장 핵심적이고 필수불가결한 솓성

본질적인 속성 외 속성을 우연적(accidental)속성이라고 한다.

예컨대 한 사람이 취직을 해서 회사원이 되어도 그 사람은 여전히 그 사람이다. 회사원이 그 사람의 본질을 바꾸지는 못한다.

클래스는 객체가 공유하는 본질적인 속성을 정의한다. 대부분의 객체지향 언어에는 우연적인 속성은 추가할 수 없다.

안타깝지만 분류 수준과 결과는 누가 분류를 하는가와 무엇을 기반으로 분류하는가에 따라 크게 달라진다. 실제로 사람들은 동일한 사물을 다양한 방식으로 인식하며 다양한 방식으로 분류한다.

자바스크립트처럼 클래스가 존재하지 않는 프로토타입 기반의 언어는 아리스토텔레스의 객관적인 분류 체계가 존재한다는 사상에 대한 철학적 의문에 그 뿌리를 두고 있다. 클래스가 없는 프로토타입 언어에서 분류와 인스턴스화는 프로토타입이라는 객체의 복사를 통해 이뤄진다.

마틴 파울러는 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

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

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

느슨한 결합을 보장

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

따라서 변경에 유리

캡슐화

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

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