전략 패턴으로 리팩토링하기

요즘은 코딩할 때 처음부터 AI한테 물어보는 것이 일반적이고 쓸 수 있는 코드 에이전트도 엄청 많아졌다. 생각해보니 내가 AI를 처음 써봤을 때는 좀 조심스럽고 제한적으로 썼던 것 같다. 코드를 바로 짜달라고 하기보단 이미 짠 코드를 리팩토링 해달라는 요청이 훨씬 많았다. 그래서 AI의 효율성보다는 개념 학습 도구의 용도로 활용했더랬다. 공부하는 그 과정이 꽤 재밌어서 그때 받았던 답변들을 글로 정리해봤다.

 

기능 및 코드의 문제점

원 기능은 id에 대한 Vo 또는 TypeCode을 각각 리턴하는 함수이다. id에 해당하는 데이터를 알아야 하므로 DB 조회는 둘 다 같은 시퀀스를 거친다. 그래서 Type을 구하는 함수는 Vo를 구하는 함수를 그대로 사용한다. 그럼에도 두 개가 서로 분리되어 있어서 종류가 추가될 때마다 유사한 작업을 각 함수마다 해야 하는 번거로움이 있다.

지금 생각해보면 조회 구문을 아예 따로 만들거나, getType… 함수를 없애는 방향으로 해봐도 될 것 같다.

private getVoById(int id) {
		MyVo vo = mapper.selectTypeA(id);
		if(vo != null) { doSomething(vo); return vo;}
		
		vo = mapper.selectTypeB(id);
		if(vo != null) { doSomething(vo); return vo;}

		// ....반복

    throw new Exception(..., ...);
}

private TypeCode getTypeById(int id) {
		MyVo vo = getVoById(id);
		if(vo instanceof MyVoA) return TypeCode.A;
		if(vo instanceof MyVoB) return TypeCode.B;		

	// .. 반복

    throw new Exception(..., ...);
}

 

리팩토링 방향

• 전략 패턴과 매핑 테이블 활용: TypeCode를 변환하는 부분까지 하나의 전략으로 구성했다.
• 람다/함수형 인터페이스 활용: 많이 반복되는 if-return 분기의 가독성을 개선했다. 람다형으로 바로 짜는 게 익숙지 않은데 개선된 코드 덕분에 공부가 많이 되었다.

// 1. Type별 조회 전략 정의
private static class MyStrategy{
    final Function<Integer, MyVo> finder;
    final Function<MyVo, MyVo> postProcess;
    final TypeCode typeCode;

    TypeStrategy(Function<Integer, MyVo> finder, Function<MyVo , MyVo > postProcess, TypeCode typeCode) {
        this.finder = finder;
        this.postProcess = postProcess;
        this.typeCode = typeCode;
    }
}

// 2. 전략 리스트 초기화 (생성자나 static 블록에서)
private final List<MyStrategy> myStrategies = Arrays.asList(
    new MyStrategy(
        mapper::selectTypeA
        vo -> { ((MyVoA)vo).doSomething; return vo; },
        TypeCode.A
    ),
    new MyStrategy(
	    mapper::selectTypeB,
      vo -> { ((MyVoB)vo).doSomething; return vo; },
	    TypeCode.B
	  )
	  
    // ... 나머지 타입도 동일하게 추가
    
);

// 3. refactoring
private MyVo getVoById(int id) {
    for (MyStrategy strategy : myStrategies) {
        MyVo vo = strategy.finder.apply(id);
        if (vo != null) {
            return strategy.postProcess.apply(vo);
        }
    }
    throw new Exception(..., "연결된 Vo가 없음", ...);
}

// 4. refactoring
private TypeCode getTypeById(int id) {
    for (MyStrategy strategy : myStrategies) {
        MyVo vo = strategy.finder.apply(id);
        if (vo != null) {
            return strategy.typeCode;
        }
    }
    throw new Exception(..., "객체가 없음", ...);
}

 

리팩토링 효과

• 가독성: Type별 처리 로직이 한 곳에 모여 있어 한눈에 파악 가능. TypeCode를 변환하는 부분까지 하나의 전략으로 구성한 덕분이다. 왜 처음 만들 때 이 생각을 안했을까.
• 확장성: 새로운 Type이 추가될 때, if 구문 반복이 아니라 전략 리스트에만 추가하면 됨
• 유지보수성: 중복 코드 최소화
• OCP 준수: 기존 코드를 건드리지 않고 새로운 전략만 추가
• 이 외에도 AI는 예외 처리 일원화 같은 것이 장점이라고 답변을 해주었으나, 그건 원래 코드에서 이미 한 거잖아…