TIL

APPENDIX C. 동적인 협력, 정적인 코드

개발자는 객체지향 프로그램을 작성하며 두 모델을 동시에 생각해야 한다.
- 프로그램 실행 구조를 표현하는 동적 모델 (dynamic model)
  - 객체지향에서 동적 모델은 객체와 협력으로 구성된다.
- 코드의 구조를 담는 고정된 정적 모델 (static model)
  - 객체지향에서 정적 모델은 타입과 관계로 구성된다.
동적 모델 기반 설계에서 중요한 것은 변경이고 설계가 필요한 이유는 변경을 수용할 수 있는 코드를 만들기 위해서다.
- 변경을 수용할 수 있는 코드란
  - 단순하다
  - 결합도가 낮다
  - 중복 코드가 없다.
변경 용이한 설계를 위해선 코드가 아닌 협력에 초점을 맞춰야 한다.
- 좋은 설계는 동적 모델을 기반으로 해야 하는 것이다.

01 동적 모델과 정적 모델

행동이 코드를 결정한다.

행동이 코드 구조에 영향을 미치는 대표적 예가 상속 계층을 구성하는 방식이다.
13장의 서브 타이핑을 설명하며 예로 들었던 Bird와 Penguine을 살펴보자.
- 행동을 제외한 채 개념 관계에 기반해 정적 모델을 구상한다면 Bird를 Penguin이 상속하게 된다.
- 하지만 fly라는 행동을 고려한다면 Bird를 FlyingBird가 상속하고, Penguin은 Bird만을 상속하게 된다.
행동을 고려하지 않는다면 날 수 있는 Penguin이 나타나거나 OCP를 위반하는 코드가 나올 수밖에 없다.

변경을 고려하라

행동을 고려하도라도 변경을 고려하지 않는다면 유지보수하기 어려운 코드가 만들어진다.
동일한 행동을 제공하는 정적 모델이 있다면 항상 변경을 부드럽게 수용할 수 있는 설계를 선택하라.

02 도메인 모델과 구현

도메인 모델에 관하여

도메인(domain) - 사용자가 프로그램을 사용하는 대상 영역
모델(model) - 지식을 선택적으로 단순화하고 의식적으로 구조화한 형태
도메인 모델(domain model) - 사용자가 프로그램을 사용하는 대상 영역에 대한 지식을 선택적으로 단순화하고 의식적으로 구조화한 형태
도메인 모델을 작성하는 것은 목표가 아니라 출발점이다.
- 궁극적 목적은 동작하는 소프트웨어를 만드는 것
- 도메인 모델은 필요한 개념과 이름의 의미, 관계에 대한 힌트를 제공하는 역할로 끝나야 한다.

몬스터 설계하기

주인공 캐릭터와 다양한 몬스터가 등장하는 게임을 설계한다고 가정하자.
Monster에는 Dragon도 있고 Troll도 있고 더 추가될 것이다.

public abstract Monster {
  private int health;
  // ...
  abstract public String getAttack();
}

public class Dragon extends Monster {
  public Dragon() {
    super(230);
  }
  
  @Override
  public String getAttack() {
    return "용은 불을 내뿜는다.";
  }
}

상속을 사용하는 경우 새로운 몬스터를 추가하면 클래스를 추가하고 메서드를 오버라이딩 하면 된다.
그런데 몬스터가 수백 종류가 된다고 할 때 수백개의 클래스를 만들고 메서드를 오버라이딩하는 것은 큰일일 것이다.
Monster 설계를 상속이 아닌 합성 관계로 가져가면 이 문제를 개선할 수 있다.

public class Breed {
  private String name;
  private int health;
  private String attack;
  
  // ...
}

public class Monster {
  private Breed breed;
  // ...
  
  public String getAttack() {
    return breed.getAttac();
  }
}

위처럼 하면 새 몬스터 추가는 클래스 추가가 아닌 새로운 Breed 인스턴스 생성과 Monster에 연결하는 작업으로 바뀐다.

Monster dragon = new Monster(new Breed("용", 230, "용은 불을 내뿜는다."));
Monster troll = new Monster(new Breed("트롤", 48, "트롤은 곤봉으로 때린다."));

TYPE OBJECT 패턴
- 인스턴스가 다른 인스턴스의 타입을 표현하는 방법
- 상속 대신 합성을 사용하라는 설계 지침을 따르는 또 다른 예다.

행동과 변경을 고려한 도메인 모델

초기에 고안한 도메인 모델은 좋은 출발점이 될 수 있다.
하지만 더 쉬운 모델이 떠올랐다면 과감히 초기 아이디어를 버려야 한다.
행동과 변경을 고려하지 않은 채 도메인 모델을 그대로 따르는 설계는 코드의 유지보수를 방해할 뿐이다.
도메인 모델은 단순히 클래스 다이어그램이 아니다.
- 도메인 핵심을 간략하게 단순화해서 표현할 수 있는 모든 것이 도메인 모델이다.

// 게임 도메인 모델은 아래와 같이 표현할 수도 있다.
{
  "breeds": 
  [
    { "name": "용", "health": 230, "attack": "용은 불을 내뿜는다." },
    { "name": "트롤", "health": 48, "attack": "트롤은 곤봉으로 때린다." }
  ]
}

도메인 모델이 단순히 정적 모델의 형태를 띨 필요가 없지만 도메인 모델을 봤을 때 코드도 함께 이해될 수 있는 구조를 찾는 것이 좋다.

분석 모델, 설계 모델, 그리고 구현 모델

분석 모델 - 순수하게 문제 도메인에 초점을 맞추며 기술적인 해결 방법을 언급해선 안 된다.
설계 모델 - 분석 모델이 완성되면 기술적 관점에서 솔루션을 서술하는 모델
구현 모델 - 설계 모델을 기반으로 프로그래밍 언어로 변환하는 모델
위 세 모델을 명확히 구분하는 것은 불가능하고 오히려 악영향을 미치지만 분석, 설계, 구현 동안 동일한 모델을 유지하는 것이 중요하다.