💡 목적 중심 이름 설계

• 이름을 대충 붙이면, 책무 얽힘 → 강한 결합 → 클래스 거대 → 갓 클래스
• 비즈니스 목적이 중요한 역할하므로, 목적 중심 이름 설계가 유효

---

10.1 악마를 불러들이는 이름

• 그냥 ‘상품’ 클래스는 갓 클래스 될 가능성 있음

1. 관심사 분리

• 관심사(유스케이스, 목적, 역할)에 따라서 분리
• 상품 클래스는 관심사에 따라 (예약상품, 주문 상품, 재고 상품, 발송 상품) 으로 분리
• 분할한 클래스에 알맞은 관심사 이름을 붙여줌
• 분할한 클래스에 알맞은 로직을 넣어서 캡슐화
• 결합도 낮추고, 응집도 올라감
• 영향범위 줄어들어, 개발 생산성 향상

2. 포괄적이고 의미가 불분명한 이름

• 목적 불명 객체
  • 이름이 너무 포괄적이라 목적이 불분명한 클래스
  • 규모 커지기 쉬움
• 관심사 분리 고려한 이름 설계 필요
• 비즈니스 목적에 따라 이름 붙이면 쉽게 가능

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

• 이름 설계
  • 소프트웨어로 달성하고픈 목적, 의도를 이름만으로 알도록 설계하는 것
  • 중요 포인트
    • 구체적, 의미 범위 좁고, 특화된 이름
    • 목적 기반 이름 (not 존재 기반)
    • 관심사 분석
    • 소리내서 이야기
    • 이용 약관 읽어보기
    • 다른 이름으로 대체가능한지 확인
    • 낮은 결합, 높은 응집도 구조인지 확인

1. 구체적, 의미 범위 좁고, 특화된 이름

• 가장 중요한 포인트!!!
• 비즈니스 목적
  • 회사가 사업적으로 지향하는 목적
• 이름과 관계 없는 로직 배제 가능
• 클래스 작아짐
• 결합도 낮아짐 → 영향 범위 줄어듬
• 특화된 이름 → 가독성
• 개발 생산성 향상

2. 존재 아니라, 목적 기반 이름

• 존재 기반 이름은 여러 곳에서 사용되기 쉬움 → 목적 불분명
  • 존재기반: 주소 / 목적기반 : 발송지, 배송지

3. 비즈니스 목적(관심사) 분석

• 소프트웨어가 추구하는 목적, 내용 모두 분석
• 등장인물과 관련된 내용 나열
• 관계 정리

4. 소리 내어 이야기

• 목적과 의도를 다르게 인식하면, 이름이 잘못된 방향으로 정해짐
• 고무 오리 디버깅
  • 문제를 설명하다보면 스스로 원인을 깨닫고 해결 가능
• 유비쿼터스 언어
  • 이야기하면서 분석하는 활동

5. 이용 약관

• 이용약관엔 서비스 관련 규칙이 굉장히 엄격한 표현으로 작성
• 비즈니스 측면에서 명확한 이름 등장
• 비즈니스 규칙 = 클래스 하도록 이름을 설계하면, 정확하고 빠르게 수정 가능

6. 다른 이름 대체 가능한지 확인

• 계속 확인하면서 더 나은 이름을 찾아봐야 함.
• 동의어 사전을 찾아보는 것도 좋은 방법

7. 결합도, 응집도 확인

• 다른 클래스 몇 개와 관련 있는지 개수 확인
• 의미가 더 좁은 특화된 이름 생각해보기
• 관련 클래스 개수가 적을 수록 좋다!!

10.3 이름 설계 시 주의 사항

1. 이름에 관심 가지

• 팀 개발에서 특히 중요
• 이름이 프로그램 구조를 크게 좌우한다!

2. 사양 변경 시 ‘의미 범위 변경’ 경계

• 사양 변경으로 의미가 변하는 경우가 존재
• 이름 설계를 중간에 검토해서 교체

3. 대화에 등장, 그러나 코드에 미등장 이름 주의

• 이름 없는 로직
  • 대화에 자주 등장하는 중요 개념이 소스 코드에 이름조차 붙어 있지 않은 경우 존재
  • 소스 코드 전반에 무분별하게 작성되는 경향
  • 메소드, 클래스로 분리되지 않은 상태
  • 변경 어려움
• 대화에서 등장하는 이름으로 메소드, 클래스 설계

4. 수식어 대신 클래스로

• 다른 의미 클래스, 조건에 따라 달라지는 대상
  • 수식어 필요
  • 차이 구별 어려움
• 수식어 붙여야 하는 대상은 각각 클래스로 구분
  • 수식어
    • 최대 체력
      • 장비 착용했을때 최대 체력
      • 장비 적용 안 한 상태의 최대 체력
  • 클래스
    • 장비 착용했을때 최대 체력
    • 장비 적용 안 한 상태의 최대 체력
• 의미가 다른 개념을 다른 클래스 설계해야 함.
  • 개념 사이 관계 이해 쉬움
  • 동료가 사용하는 수식어에 유의

10.4 의미를 알 수 없는 이름

• tmp 같은 거

1. 기술 중심 명명

• 기술 중심 용어는 소프트웨어 구현하는 방법인 것 뿐
  • 따라서 임베디드 처럼 하드웨어와 직접 관련 있는 경우 제외하고 지양
• 비즈니스 목적에 따라 이름 지어야 함 → 목적 중심 명명

2. 로직 구조 나타내는 이름

• 내부 로직에 대해서 나타내는 이름 지양
• 의도, 목적을 알 수 있는 이름 지향

// 로직 구조 나타내는 이름
boolean isMemberHpMoreThanZeroAndIsMemberCanActAndIsMember...() {...}

// 의도, 목적 중심 이름 설계
boolean canEnchant(...)

3. 놀람 최소화 원칙

• 예상치 못한 놀람을 최소화하도록 설계해야 한다는 접근 방법
• 로직과 이름을 잘 대응하면 해결
• 어떤 의도, 목적을 가진 이름을 가진 로직에 이름과 다른 로직이 섞여 있으면 안 된다는 의미.

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

1. 데이터 클래스처럼 보이는 이름

• ~Info, ~Data 같은 이름
• 데이터만 갖는 클래스라고 선입견 갖게 됨.
• 이런 이름을 지양하고, 관련 로직을 모아서 캡슐화를 지향해야 함.
• DTO (Data Transfer Object)
  • 명령 쿼리 역할 분리(CQRS) 아키텍처 패턴에서 사용하는 클래스
  • 데이터 전송 용도로만 사용
  • 인스턴스 변수 final
  • 생성자에서는 값 지정만
  • 참조 용도로만 사용하므로, setter 없어야 함

2. 클래스를 거대하게 만드는 이름

• Manager(관리), Processor, Controller 같은 이름
• 이름이 가진 의미가 너무 넓고 애매하기 때문
• MVC 패턴 Controller에서는 전달받은 요청 매개변수를 다른 클래스에 그저 전달하기만 하는 역할.
  • 안에 서비스 로직이나, 조건 분기가 있으면 안 됨

3. 상황에 따라 의미가 달라질 수 있는 이름

• 컨텍스트에 따라 클래스를 분리해야함.
• 각 컨텍스트를 패키지로 구분
• 각 패키지(컨텍스트)에 의미 달라지는 클래스를 구현
• 각 컨텍스트에서 사용하는 개념을 클래스로 구현
• 서로 다른 컨텍스트 끼리 강한 결합을 느슨한 결합으로 바꾼 것

4. 일련번호 명명

• 목적, 의도 알기 어려움
• 구조 개선 어려움
• 암튼 고-얀 놈

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

1. 동사 + 목적어 형태 메소드 이름 주의

• 관계 없는 책무 가진 메소드일 가능성

2. 메소드 이름은 동사 하나가 좋음

• 필요한 개념을 잘게 쪼개다보면, 메소드 이름은 자연스럽게 동사 만 필요하게 됨.

3. 부적절한 위치의 boolean 메소드

• 적절하지 않은 클래스에 구현된 경우가 있을 수 있음
• 클래스 is 상태 형태가 자연스러우면 제대로 된 위치

10.7 이름 축약

1. 의도를 알 수 없는 축약

2. 이름 축약 지양

3. 이름 축약 가능한 경우

• 일반적으로 축약한 이름이 통용되는 경우
  • sns, vip
• 관습적으로나, 통상적으로 의미를 해치지 않는 경우
  • for 문에서 사용하는 i, j 변수