Enum 열거형 클래스 (내가 취하지 못한 장점들)

그동안 코딩을 하며 내게 이상한? 원칙이 생긴 것 같다.

 

최근 소규모 프로젝트를 하며 느낀 것인데, 나는 항상 Colmn의 값이 2개로 제한되는 상황이 생기면 아래와 같이 Enum 방식을 고의로 사용하지않고 Y혹은 N 아니면 True혹은 False로 처리했던 것 같다.

(에러 처리를 할 때는 개수가 많아지다보니 그때는 Enum을 활용하여 에러코드를 관리하였다)

 

그러던 와중 문득 이런 생각이 들었다.

 

"Enum을 사용하여 열거를 해놓으면 나중에 생길 경우의 값도 대비할 수 있으니 좋겠지만, 나는 2개만 될 것이 확실하기에 Enum을 쓰지않았다. 근데 이런 내 생각이 맞는 것일까? Enum의 다른 장점이 더 있지는 않을까? 너무 섣부른 판단은 아니였을까?"

 

그래서 Enum을 쓰면 좋은 점에 대해 열거해보려고 한다.

 

▼ 기존에 짰던 어리석은 프로젝트 코드 ▼

@Entity
@Getter
@NoArgsConstructor(access = AccessLevel.PROTECTED)
@Slf4j
public class FixedExtension extends BaseTimeEntity {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Column(name = "fixed_id")
    private Long id;

    @NotNull
    @Column(name = "fixed_name")
    private String fixedExtensionName;
    @NotNull
    @Column(name = "fixed_checked")
    private String isChecked = "N";
    
    public void changeChekced() {
        if (this.isChecked.equals("N")) {
            this.isChecked = "Y";
        } else {
            this.isChecked = "N";
        }
    }
}

 

Enum 사용 시 장점

1. 코드가 단순해지며, 가독성이 좋아져 소스관리가 쉽다.

2. 허용 가능한 값들을 제한할 수 있다.

3. 리팩토링 시 변경 범위가 최소화된다. (내용의 추가가 필요하더라도, Enum 코드 외에 수정할 필요가 없다)
4. 인스턴스 생성과 상속을 방지하여 상수값의 타입안정성이 보장된다.

5. enum class를 사용해 새로운 상수들의 타입을 정의함으로 정의한 타입이외의 타입을 가진 데이터값을 컴파일시 체크한다.
6. 키워드 enum을 사용하기 때문에 구현의 의도가 열거임을 분명하게 알 수 있다.

7. 열거형 상수간의 비교는 ==을 사용할 수 있다. equals()가 아닌 == 연산자로 비교한다는 것은 그만큼 빠른 성능을 제공한다는 이야기이다. 

 

 

프로젝트 코드 진행 시 문제상황 시나리오로 보는 Enum의 필요성

1. 만약 협업하는 누군가가 실수로 엔티티를 생성할 때 True / False를 수기로 넣어서 생성할 시에 changeChecked메소드가 실행되지 않을텐데? 그러니 타입안정성을 보장할 수 있는 방식이 더욱 안전할텐데?

 

2. 어떠한 이유로 인해 "Y" / "N" 값이 아닌, 다른 특정한 값으로 바꿔야 하는 이유가 생겼을 때 코드 전체를 수정하게 되어 유지보수가 힘들어질텐데?

 

3. 만약 속도개선이 더 필요한 상황이라면? 그렇기 때문에 equals() 보다는 == 연산자를 사용한 if문으로 성능개선을 더욱 해야하는 상황이라면?

 

4. 불필요한 반복성 코드로 인해 다른 팀원들이 읽었을 때 가독성이 떨어지기에, 협업을 위한 간결한 코드가 필요한 상황이라면?

    @NotNull
    @Column(name = "fixed_checked")
    private String isChecked = "N";
    
    public void changeChekced() {
        if (this.isChecked.equals("N")) {
            this.isChecked = "Y";
        } else {
            this.isChecked = "N";
        }
    }
}

 

현재 내 수준에서는 위 4가지 이유로 인해서 앞으로는 Enum을 적극 차용하는 것이 보다 좋은 프로젝트를 위한 방안이 되었다.

 

참 부끄럽다. 

예전에 어떤 프로젝트를 하던 당시, 팀원분께서 Y 혹은 N이 배정되는 Column을 Enum으로 관리하자고 했던 때가 있었다.

그때 나는 "2개로만 진행될텐데 Enum은 너무 과한 거 같으니 그냥 Y혹은 N으로 관리하는 방향은 어떠실까요?" 라고 했었다. 그당시에는 설득력이 있던 주장으로 받아들여주셨는지, 그렇게 진행하기로 협의가 되었었다. (죄송합니다 OO님..)

 

언제나 가장 무서운 것은 신념을 가진 바보인 것 같다.

 

이제는 알았으니, 나중에 이런 경우가 생기면 Enum을 적극 차용하여 사용해야겠다.

 

그때 어리석은 판단을 공유해드렸던, 그리고 최근 자주 연락하는 OO님!

이 글로 사과를 드립니다.. ㅎㅎㅎ

 

나중에 실제로 만나뵙게되면 그때 또 사과드리겠습니다 ㅎㅎ

오늘도 화이팅입니답.