10. 이름 설계 - 구조를 파악할 수 있는 이름

내용

---

악마를 불러들이는 이름

• 흔히 볼 수 있는 좋지 않는 이름 설계는 상품을 그대로 '상품 클래스' 라고 이름 붙이는 것.

• 관심사 분리?

  • 유스케이스, 목적, 역할에 따라 분리한다.

• 그냥 상품이 아니라..

  • 예약 상품

  • 주문 상품

  • 재고 상품

  • 발송 상품

이름 설계하기 - 목적 중심 이름 설계

• 이름을 붙이는 건 '설계'

  • 설계란?

    • 어떤 문제를 해결하기 위한 구조를 생각하거나 만들어 내는 것.

• 이름은 느슨한 결합, 응집도가 높은 구조를 만드는데 중요한 역할을 한다.

• 중요 포인트

  • 최대한 구체적, 의미 좁게, 특화된 이름

  • 존재가 아니라 목적 기반

  • 어떤 관심사가 있는지 분석

  • 소리 내어 읽어보고

  • 이용 약관 읽어보고

  • 다른 이름으로 대체할 수 없는지 검토해보고

  • 결합이 느슨하고 응집도가 높은 구조인지 검토

• 최대한 구체적, 의미 좁게, 특화된 이름

  • 클래스가 작아지고

  • 관계된 클래스가 적으므로 결합도가 낮아지고,

  • 관계된 클래스가 적으므로, 변경 시 영향범위가 좁음

  • 개발 생산성 향상

• 존재가 아니라 목적 기반

  • bad -> 주소

  • good -> 발송지, 배송지

• 유비쿼터스 언어?

  • 팀 전체에서 의도를 공유하기 위한 언어

• 결합이 느슨하고 응집도가 높은 구조인지 검토

  • 여러 의미를 갖고 있다면 분해하자

  • 관련된 클래스 개수가 적으면 적을 수록 느슨하고 응집도 있는 구조일 가능성이 높음

이름 설계 시 주의 사항

• 수식어를 붙여서 차이를 나타낸다면..

  • e.g. 이 플래그가 true인 User는 문제 있는 회원

    • 각각을 클래스로 설계할 수 없는지 검토해보기.

의미를 알 수 없는 이름

• 놀람 최소화 원칙

  • 예상하지 못한 놀라움을 최소화하도록 설계해야 한다.

구조에 악영향을 미치는 이름

• ~info, ~data는 데이만 갖는 클래스니까 로직을 구현하면 안되는 것 같은 느낌

• DTO (Data Transfer Obejct)

  • 단순 데이터 전송 용도면 괜찮다.

  • 그런데 값을 변경하는 용도는 지양

• Manager, Processor, Controller

  • 여러 책무를 떠안기 쉬움.

이름을 봤을 때, 위치가 부자연스러운 클래스

• Enemy 클래스의 관심사는 적

  • Enemy.addItemToParty

    • 관심사가 다른 메서드는 '동사 + 목적어' 형태가 되는 경향이 있음

• 가능하면 메서드 이름은 동사 하나로 구성되게 하기

• 클래스 is 상태

  • This member is hungry -> good

  • Common is member in confusion -> bad

    • member is in confusion -> good

이름 축약

• 기본적으로 이름은 축약하지 말자

정리

---

• 책무가 다른 로직은 다른 클래스로 정의하자

• 이름은 '설계' 하는 것

• 목적을 생각하고, 사용하자

참고

---

• https://product.kyobobook.co.kr/detail/S000202521361