[Java] Enum 활용 및 개선

지금까지 Enum를 꽤나 적극적으로 사용해왔지만, 그저 허용 가능한 값을 제한하고 코드 내의 매직 넘버가 노출되지 않도록 하는 용도 정도로만 생각하고 사용했다. 그러다 최근 정적 펙토리 메서드에 대한 공부 중, 인스턴스가 하나만 만들어짐을 보장한다는 측면에서 Enum에 대한 언급이 있었다. 이에 이번 기회에 Enum에 대해 공부하고 기존 프로젝트의 Enum 파트 코드를 리팩터링해보고자 한다.

 

---

 

 

☑️ Enum 활용

1. 상태와 행위를 한 곳에서 관리

이는 Enum 리팩터링을 진행하게 된 가장 큰 원인이다. 기존 프로젝트의 알림 파트는 메시지 Content를 Dto에 포함시키고자 Dto의 생성자에서 NotificationTopic이라는 Enum 값에 따라 Content를 설정하는 방식으로 구현되어 있었다.하지만 아래 코드와 같이 생성자가 많은 일을 하는 것은 코드의 유지보수성과 가독성 측면에서 좋지 않고 코드의 복잡성을 증가시키며 객체 생성의 책임을 벗어난 논리를 포함하게 된다.

리팩터링 전 코드

 

따라서 아래와 같이 NotificationDto의 생성자는 초기화의 책임만 가지고, Enum 값에 대한 상태와 행위를 Enum에 응집시킨다면 Enum의 상태가 수정, 추가될 때 책임이 없는 타 클래스 메서드의 변경을 막을 수 있을 것이다.

 

행위를 Enum에 포함시키는 방법으로는 추상 메서드를 활용하여 상수별로 메서드를 추가하는 방법과 Function인터페이스를 사용하는 방법이 있다. 해당 프로젝트에서는 Java11을 사용하고 있기 때문에 Function 인터페이스를 사용하여 리팩터링을 진행했다.

추가적으로 Content 문자열을 message.properties 리소스 파일로 분리한다면 유지보수나 로컬라이즈 편의성이 높아진다.

 

 

 

2. 데이터 간의 연관관계 표현

사실 이 두 번째 이점은 Enum을 사용한다면 당연히 알아야 할 내용이라고 생각하기 때문에 간단하게 짚고 넘어갈 것이다.

아래 코드와 같이 매직 넘버를 사용하여 코드를 작성한다면 매직 넘버 사이의 연관성을 명확히 알 수 없게 된다는 단점이 있다. 또한 만약 "Y" 뿐 만 아니라 "T", "F"와 같은 키워드가 여러 개 추가된다면 추가되는 키워드 개수만큼 분기문이 늘어나게 되면서 반복성 코드가 많아지게 된다.

public class Impl{
	public String toIntValue(String origin){
    	if ("Y".equals(origin)) return "1";
    	else return "0";
    }
    public String toBoolValue(String origin){
    	if ("Y".equals(origin)) return true;
        else return false;
    }
}

 

이러한 문제점들을 해결하기 위해서 다음과 같이 Enum을 사용할 수 있다. 아래 코드를 통해 Y, 1, true가 모두 같은 의미로 사용된다는 것을 파악할 수 있고, 메서드 또는 분기문의 추가 없이 필드값만 추가함으로써 키워드 추가가 가능하게 된다.

@Getter
public enum TempStatus{
    Y("1", true),
    N("0", false);
    
    private String intValue;
    private Boolean boolValue;
    
    TempStatus(String intValue, Boolean boolValue){
    	this.intValue = intValue;
        this.boolValue = boolValue;
    }
}

 

 

3.  데이터 그룹 관리

5가지로 이동수단을 분류하고 각 이동수단 별로 여러 타입이 존재할 때, 연관관계를 나타내기 위해서는 분기문 사용, DB 저장 후 조회 등의 방법이 있다. 하지만 이들은 OCP 위반, 조회 쿼리로 인한 속도 저하 등의 명확한 단점들이 존재하는 반면, Enum은 효율적이고 객체지향적인 코드 작성이 가능하다는 장점을 가지고 있다.

public enum Vehicle {
    CAR(100, List.of(CAR_SEDAN, CAR_COUPE, CAR_SUV)),
    MOTORCYCLE(50, List.of(MOTORCYCLE_SPORTBIKE, MOTORCYCLE_CRUISER, MOTORCYCLE_TOURER)),
    TRUCK(200, List.of(TRUCK_PICKUP, TRUCK_LORRY, TRUCK_TRACTOR)),
    BICYCLE(0, List.of(BICYCLE_MOUNTAIN, BICYCLE_ROAD, BICYCLE_HYBRID)),
    BOAT(300, List.of(BOAT_SAILBOAT, BOAT_MOTORBOAT, BOAT_YACHT));

    private int fuelConsumption;
    private List<VehicleCode> vehicleCodeList;

    Vehicle(int fuelConsumption, List<VehicleCode> vehicleCodeList) {
        this.fuelConsumption = fuelConsumption;
        this.vehicleCodeList = vehicleCodeList;
    }

    public int getFuelConsumption() {
        return fuelConsumption;
    }

    public List<VehicleCode> getVehicleCodeList() {
        return vehicleCodeList;
    }
    
    public static Vehicle findByVehicleCode(VehicleCode code){
    	return Arrays.stream(Vehicle.values())
            .filter(vehicle -> vehicle.hasVehicleCode(code))
            .findAny()
            .orElse(EMPTY);
	}

    public boolean hasVehicleCode(VehicleCode code){
        return VehicleCodeList.stream()
                .anyMatch(vehicle -> vehicle == code));
    }
}

 

 

---

 

☑️ 결론

이번 리팩터링에서 상태와 행위를 한 곳에 응집시킴으로써 코드의 복잡성을 낮추고 유지보수성을 높일 수 있었다. 이를 통해 코딩을 할 때 내가 작성하고 있는 코드가 객체지향적 코드인지, 객체지향 원칙을 위반하고 있지는 않은지, DRY한 코드인지를 체크하고 경계하는 습관의 필요성을 체감할 수 있었다.