들어가며

Java 문법을 활용하여 계산기 프로그램을 작성하던중, 연산자를 Enum으로 정의하는 과정에서 들었던 생각을 정리해보았다.

이름만 있는 Enum, 그게 무슨 의미가 있을까

우선 처음에는 Enum에 PLUS, MINUS… 등을 정의하였다.
그리고 연산문에서 switch문으로 해당 ENUM을 사용하였다.

기존코드

변경코드

의미 추가하기 - 심볼과 같이 관리

그래서 각 연산자에 해당하는 기호(+, -, …)를 필드로 추가해 의미를 강화했다. Operation.PLUS.getSymbol() 식으로 표현이 가능해져 코드도 읽기 쉬워졌다.

기능 추가하기 - 람다식으로 연산까지 표현해보자

이왕 연산자라면, 연산 기능도 Enum에 포함하면 어떨까? (a, b) -> a + b 같은 람다식으로 연산을 Enum 상수에 바로 담을 수 있었다. 한 줄짜리 Enum 선언이 강력해졌고, 실제 연산까지 책임지는 구조가 되었다.

제네릭화에서 마주한 벽

여기서 문제 발생. 연산 대상이 꼭 int일 필요는 없어서, 연산자 인터페이스를 제네릭으로 만들고 싶었다. 하지만 Enum의 제네릭 처리와 타입 추론이 매끄럽지 않았다.

돌아보니 Enum이 너무 많은 역할을 한다

Enum이 모든 걸 책임지려다 보니 복잡성이 폭발하기 시작했다.

•	상수 이름 역할  
•	기호를 제공  
•	연산 기능을 수행  
•	타입 제약을 고민  
•	복잡한 로직까지 포함

역할 정리: Enum이 진짜로 해야 할 일

•	Enum: 의미와 상징만 담당 (이름 + 기호 정도)
•	기능 구현: 별도의 전략 객체나 함수로 분리
•	제네릭 로직: Enum이 아닌, 외부에서 다루도록 변경

Enum은 Enum답게, 책임을 줄이며 구조 개선하기

Enum은 결국 상수 집합이라는 본질에 집중해야 한다. 지나치게 기능을 붙이다 보면 유지보수가 어렵고 유연성도 떨어진다. Enum은 역할을 최소화하고, 복잡한 처리는 외부로 위임하는 게 이상적이다.

결론 – 객체지향 설계의 균형 감각

기능을 붙이는 건 쉽지만, 책임을 걷어내는 건 어렵다. 객체지향 설계는 늘 ‘적절한 책임 분산’을 고민하게 만든다. Enum은 강력하지만, 적당히 써야 진짜 강력해진다.

댓글남기기

참고