Enum 파헤치기 🧹

Enum 🧾

Enum이 생겨난 이유

본격적으로 Enum이 무엇인지 알아보기 전에, 왜 Enum이 등장하게 되었는지를 먼저 알아보자 😛

비즈니스 요구사항

사용자는 다양한 결제 수단을 선택할 수 있으며, 결제 방식에 따라 서로 다른 전략이 실행된다. 현재 제공되는 결제 수단은 다음과 같다:

• kakao : 카카오페이를 통해 결제
• naver : 네이버페이를 통해 결제
• bad : 불안정한 테스트용 결제 수단 결제 수단을 입력하면, 해당 방식에 맞는 결제 전략 객체를 생성해야 한다.
• 정의되지 않은 결제 수단을 입력할 경우 예외를 발생시킨다.

---

🔍 문자열 기반 방식

사용자가 선택한 결제 수단에 따라 결제 수단을 제공하는 클래스를 만들어보자.

# StrategyFactory
public class StrategyFactory {
    public static PayStrategy of(String payOption, int amount){
        if("kakao".equals(payOption)){
            return new KakaoStrategy(payOption, amount);
        } else if("naver".equals(payOption)){
            return new NaverStrategy(payOption, amount);
        } else if("bad".equals(payOption)){
            return new BadStrategy(payOption, amount);
        } else {
            throw new IllegalArgumentException("해당 전략이 없습니다.");
        }
    }
}

⚠️ 문제점

• 오타에 취약 : "KAKAO", "kakao"등 다양한 표기로 입력 가능 -> 오류 발생
• 컴파일 타임 검증 불가 : 잘못된 문자열도 런타임전까지는 알 수 없음
• 디버깅이 어려움 : 문제가 발생해도 원인을 찾기 어려움

✅ 문자열 상수 사용(조금 나아진 방식)

# PayOption
public class PayOption {
    public static final String KAKAO = "KAKAO";
    public static final String NAVER = "NAVER";
    public static final String BAD = "BAD";
}

# StrategyFactory
public class StrategyFactory {
    public static PayStrategy of(String payOption, int amount){
        if(PayOption.KAKAO.equals(payOption)){
            return new KakaoStrategy(payOption, amount);
        } else if(PayOption.NAVER.equals(payOption)){
            return new NaverStrategy(payOption, amount);
        } else if(PayOption.BAD.equals(payOption)){
            return new BadStrategy(payOption, amount);
        } else {
            throw new IllegalArgumentException("해당 전략이 없습니다.");
        }
    }
}

👍 개선점

• 상수를 통해 문자열 입력보다 안정성 향상
• 잘못된 상수명을 입력하면 컴파일 타임에 오류 발생

⚠️ 문제점

• 여전히 String 타입이므로, 잘못된 문자열 입력 가능성은 남아 있음
• 누군가 실수로 PayOption.KAKAO 대신 "kakao" 입력하면 검증 불가
• StrategyFactory.of(String payOption, int amount) 메서드를 사용하는 입장에선 올바른 값이 무엇인지 알기 어려움

---

🔐 타입 안전 열거형 패턴

String을 아예 쓰지 않고, 사전에 정의된 객체만 사용할 수 있도록 만들면 어떨까?

# PayOption
public class PayOption {
    private PayOption(){}
    public static final PayOption KAKAO = new PayOption();
    public static final PayOption NAVER = new PayOption();
    public static final PayOption BAD = new PayOption();
}

# StrategyFactory
public class StrategyFactory {
    public static PayStrategy of(PayOption payOption, int amount){
        if(payOption == PayOption.KAKAO){
            return new KakaoStrategy(payOption, amount);
        } else if(payOption == PayOption.NAVER){
            return new NaverStrategy(payOption, amount);
        } else if(payOption == PayOption.BAD){
            return new BadStrategy(payOption, amount);
        } else {
            throw new IllegalArgumentException("해당 전략이 없습니다.");
        }
    }
}

👍 개선점

• ==으로 비교하므로 오타 걱정 X
• 타입으로 제한 -> 잘못된 값 입력 불가
• 데이터 일관성 보장

⚠️ 문제점

• 직접 구현해야할 코드가 많음
• private 생성자 등의 패턴을 반복적으로 작성해야 함

---

🏆 최종 개선 : Java Enum 활용

자바에서는 위처럼 복잡한 구현을 단순화할 수 있도록 Enum을 제공한다.
이제 Enum을 활요하여 전략을 안전하고 편리하게 관리해보자.

# PayOtion Enum
public enum PayOption {
  KAKAO {
    @Override
    public PayStrategy createStrategy(int amount) {
      return new KakaoStrategy(this, amount);
    }
  },
  NAVER {
    @Override
    public PayStrategy createStrategy(int amount) {
      return new NaverStrategy(this, amount);
    }
  },
  BAD {
    @Override
    public PayStrategy createStrategy(int amount) {
      return new BadStrategy(this, amount);
    }
  };

  public abstract PayStrategy createStrategy(int amount);
}

# StrategyFactory
public class StrategyFactory {
    public static PayStrategy of(PayOption payOption, int amount){
       return payOption.createStrategy(amount);
    }
}

# PayMain
public class PayMain {
    public static void main(String[] args) {
        PayStrategy payment = StrategyFactory.of(PayOption.KAKAO, 1000);
        payment.processPay();
    }
}

Enum 내부에서 전략을 생성한 이유

각 Enum 상수(KAKAO, NAVER, BAD) 가 고유한 전략 생성 방식을 가지고 있으므로, switch, if-else 없이도 다형성을 통해 깔끔하게 동작을 정의할 수 있다.

장점

• 타입 안정성 보장 : 정의된 enum 값 외에는 사용 불가
• switch/if 없이 동작 정의 가능
• 코드 응집도 향상 : 전략 로직을 enum 안에 넣을 수 있음
• OCP(개방-폐쇄 원칙) 만족 : 새로운 결제 방식 추가 시 기존 코드 변경없이 enum에만 추가하면 됨