13장 모델링: 클래스 설계의 토대

13.1 악마를 불러들이기 쉬운 User 클래스

• 로그인 사용자를 나타내는 User 클래스는 사양 변경이 굉장히 잦아서 여러 가지 문제를 일으키기 쉬운 클래스이다.
• 처음에는 식별 ID만 존재하다가 email, password 등이 추가되고 할인 포인트, 자기소개, 법인 등록번호 등등 다양한 인스턴스 변수를 추가하는 상황이 발생할 수 있다.
• 그러다보면 null로 인한 문제나 기타 유효성 검사와 관련된 사소한 문제가 다양하게 발생할 것이다.
• 이런 문제는 왜 발생할까? 모델링을 제대로 하지 않았기 때문이다.

13.2 모델링으로 접근해야 하는 구조

13.2.1. 시스템이란?

• 예를 들어, 사람은 두 다리를 움직이며 이동하는 ‘이족 보행 시스템’을 따르는데, 자동차와 비행기 등 다른 시스템으로 대체하여 활용할 수 있다.
• 목적 달성을 더 효율적으로 하기 위해서 또 다른 시스템을 만들어 내는 것이다.
• 즉, 시스템은 목적 달성을 위한 수단이다.

13.2.2. 시스템 구조와 모델링

• 시스템 구조를 설명하기 위해 단순한 상자로 도식화한 것이 모델이다.
• 즉, 모델이란 특정 목적 달성을 위해 최소한으로 필요한 요소를 갖춘 것이다.

13.2.3. 소프트웨어 설계와 모니터링

• 예를 들어 온라인 쇼핑몰은 상품 매매를 시스템화한 것이다.
• 상품을 모델로 나타내면 상품명, 원가, 가격, 제조업체, 부품 재료, 유통기한 등 전부 나열하기엔 너무 많은 내용이 있을 것이다.
• 모델은 ‘특정 목적 달성을 위해서, 최소한으로 필요한 요소를 갖춘 것’이다. 따라서 목적으로 생각해야 한다.
• 주문 시에는 상품명, 판매 가격, 재고 수량 등이 최소한으로 필요한 요소들일 것이다.
• 배송 시에는 상품 가격이나 재고 수량은 따로 고려하지 않아도 된다.
• 즉, 목적에 따라 상품의 모델이 달라지는 것이다.

13.3 안 좋은 모델의 문제점과 해결 방법

• 다시 처음 예시로 돌아가서 User 클래스의 문제점은 ‘여러 목적에 무리하게 사용되고 있으며, 모델링된 것처럼 보이지만 모델링되어 있지 않다.’ 는 점이다.
• 이런 모델을 일관성 없는 모델이라고 부른다.

13.3.3. 목적별로 모델링하기

• 현실 세계에 있는 물리적인 존재와 정보 시스템에 있는 모델이 무조건 일대일 대응되지 않고, 일대다 대응되는 경우가 많다.
• 따라서 현실 세계에 있는 고객을 목적에 따라 여러 개의 모델로 정의하여 개인 계정, 법인 계정, 프로필 등으로 나누는 것이 바람직하다.
• 또, UserManager처럼 의미 범위가 너무 넓으면 안된다.
• 예를 들어, UpdateProfileUseCase 클래스처럼 목적에 따라 클래스를 분해하는 것이 좋다.

13.3.4. 모델은 대상이 아니라 목적 달성의 수단

• 모델링이 제대로 되지 않는 원인은 모델을 단순한 ‘대상’으로 해석하고 있기 때문이다.
• 모델은 시스템 전체가 아니라 특정한 목적 달성과 관련된 부분만 추려 표현한 시스템의 일부이다.
• 목적 중심으로 이름을 잘 설계하면, 목적을 달성하기에 적절한 모델을 설계할 수 있다.

13.3.5. 단일 책임이란 단일 목적

• 클래스가 이루어야 하는 목적은 반드시 하나여야 한다.
• 특정 목적에 특화되게 설계해야, 변경하기 쉬운 고품질 구조를 갖게 된다.

13.3.6. 모델을 다시 확인하는 방법

• 해당 모델이 달성하려는 목적을 모두 찾아낸다.
• 목적별로 모델링을 다시 수정한다.
• 목적 중심 이름 설계 기반으로 모델에 이름을 붙인다.
• 모델에 목적 이외의 요소가 들어가 있다면 다시 수정한다.