if문을 줄이는 방향에 대한 고찰

WAS를 이어서 개발중에 response 반환형을 index.html에서 json등으로 확장하기위해서 hashmap 형태를 byte[]로 변환했고 이 과정에서 각기 다른 html, css, js를 if 문으로 casework하기에는 가독성이 너무 떨어지기 때문에 어떻게 처리해야될까 고민하게 되었다.

if(MIME == HTML){
	//
}
else if(MIME == CSS){
	//
}

 

이런형태가 되지 않을까 싶다. MIME타입의 경우에는 개수가 정해져있어서 switch문등으로 처리해 줄 수 있지 않을까 싶지만 비슷한 다른 상황에 확장가능성까지 고려한다면 어떻게 해야할까? 

 

예전에도 비슷한 상황이 카카오테크캠퍼스 최종프로젝트 때 있었다.

당시에는 gpt한테 물어볼 생각을 못해서 멘토님께 물어봤는데 친절하게 답변해 주셨던 것같다.

네이버 카페처럼 이러한 필터링을 구현해야되는데

 

내 머릿속에는 이렇게 처리하는 방법밖에 생각나지 않았던 것이다. 직관성만 보면 정말 높지만 가독성과 확장성이 좋은코드 라고는 생각되지 않는다.

 

@RestController
@RequestMapping("/search")
public class SearchController {

    @Autowired
    private MentorPostJPARepository mentorPostJPARepository;

    @GetMapping
    public Page<MentorPost> search(@RequestParam String category, @RequestParam String keyword) {
        SearchCategory searchCategory;
        try {
            searchCategory = SearchCategory.valueOf(category.toUpperCase(Locale.ROOT));
        } catch (IllegalArgumentException e) {
            throw new ResponseStatusException(HttpStatus.BAD_REQUEST, "Invalid category");
        }
        return searchCategory.execute(keyword, mentorPostJPARepository);
    }
}


public enum SearchCategory {
    ALL((keyword, repo) -> repo.findAll()),
    TITLE((keyword, repo) -> repo.findAllByTitleKeyword(keyword)),
    WRITER((keyword, repo) -> repo.findAllByWriterKeyword(keyword)),
    INTEREST((keyword, repo) -> repo.findAllByInterestKeyword(keyword));

    private final BiFunction<String, MentorPostJPARepository, Page<MentorPost>> function;

    SearchCategory(BiFunction<String, MentorPostJPARepository, Page<MentorPost>> function) {
        this.function = function;
    }

    public Page<MentorPost> execute(String keyword, MentorPostJPARepository repository) {
        String keywordForSearch = "%" + keyword + "%"
        return function.apply(keywordForSearch, repository);
    }
}

 

그리고 예제 코드로써 주신부분은 다음과 같이 enum형과 BiFunction을 이용하여 Enum마다 다른 함수를 호출하게 매핑해주는 형식이다.이런 비슷한 상황을 다시 만나게 되어 가장 처음에 있는 형태를 어떻게 구현해야 되는지 고민하게 되었고 팩토리 패턴이란걸 알게되었다. 다를 순 있지만 방향성은 비슷해 보인다. 결론 적으로는 처음 코드는 규모가 작아 그냥 if문으로 처리했지만, WAS 설계부분에 적어놓은 것 처럼 api요청을 처리하는 로직을 팩토리 패턴과 비슷한 형식으로 처리 하였다.

 

 

후기

DesignPattern이라는 개념이 있다. 내가 아는건 게임개발에서 많이 사용한 싱글톤 패턴 밖에 없지만 실제로 싱글톤 패턴의 정의를 보면 내가 썼던 방식이 잘못된 방식이라는 것을 알게되었다. Decoration Pattern, Adapter Pattern등 정말 많은 패턴들이 있지만 각각의 패턴들의 정의만 보면 정말 어떤 상황에 왜 쓰는지 모르게 되지만 내가 어떠한 시스템을 직접 구현하면서 이상황에 이럴때를 대비한 뭔가 있을 것 같은데 라는 생각으로 접근하고 알게된 지식은 더욱더 기억에 남는것 같다.