굳이, 팩토리 클래스 활용하기

팩토리 클래스로 객체 생성 로직을 분리하면 가독성과 유지보수성을 높이는데 유용하다. 과거 실무에서 이를 적용할 기회가 있었고, 그때의 경험을 되짚어보면 과연 그때 꼭 그렇게 할 필요가 있었을까 하는 생각도 든다. 이 글에서는 당시 상황을 되짚어보면서 굳이 변경하지 않아도 될 이유와 그럼에도 불구하고 변경해야할 이유에 대해서 정리해본다.

 

하지 않아도 됐을 것 같은 이유

1. 변경 가능성이 낮아 보여서

변경 대상이 됐던 코드는 정부 기관에서 제공되는 SDK 내 API 몇 개였다. 해당 API들은 공통적으로 자주 사용되던 코드였던 만큼, 추후 변경 가능성이 낮아 보였다. 그냥 한번 개발해 두면 또 볼 일이 있을까 싶은 그런 API였다.

 

2. 대상이 많지 않아서

SDK 내 API를 많이 사용해야 하는 상황도 아니었다. 당장에는 4~5개 정도의 일부 API만 사용하는데, 이 정도 수의 API에 유지보수성을 고려하는 것이 오버엔지니어링으로 느껴졌다. API를 더 추가할 가능성도 많지 않았다.

 

3. 로직이 크게 복잡하지는 않아서

라인 수가 길긴 했지만, 찬찬히 보면 생각보다 복잡하진 않아서 약간의 시간을 투자하면 머릿속에 동작이 그려지는 정도였다. 

 

 

한다고 나쁠 건 없었던 이유

1. 값 세팅 로직이 길어서

API가 차지하는 라인이 불필요하게 길어 보였다. 그중 객체 생성을 위해 값을 세팅하는 코드가 가장 눈에 띄었다. 생성하는 객체도 여러 개인 데다 대부분 Map으로 값을 하드 하게 전달하다 보니 파라미터 의미와 쓰임을 식별하기가 어려웠다. 따라서 팩토리 클래스로 로직을 분리하면 가독성이 향상될 여지가 많았다.

// 당시 코드 예시


String a = "뭔지모를 값";          
requestBodyMap.put("a", a);         
requestBodyMap.put("b", "12341234");          
requestBodyMap.put("c", "asdfasdf");
// ... 생략 

// 위와 같이 값을 세팅하는 코드가 반복됨

 

2. 주석이 많아서

주석이 친절했지만 길었다. 주석 때문에 라인이 불필요하게 구분되면서 가독성을 많이 해쳤다. 그러나 필요한 내용이 많았고, 공식적으로 제공된 내용이니 혹시 나중에 필요할까봐 그냥 지워버리기에는 부담이 됐다. 이러한 상황에서 객체 생성 로직이라도 분리하면 관련 주석도 같이 분리될 수 있었기에 가독성을 높일 것이라고 봤다.

 

3. 공통된 파라미터가 많아서

API 모두 공통으로 사용되는 값이 많아 해당 값들만 정리해 두면 쉽게 변경이 가능한 상황이었다. 

// 공통 파라미터를 팩토리 클래스에서 관리한 예시

// API Request Object
class ApiRequest {
    private String url;
    private String header;
    private String body;

    public ApiRequest(String url, String header, String body) {
        this.url = url;
        this.header = header;
        this.body = body;
    }
}

// Factory Class
class ApiRequestFactory {
    private static final String BASE_URL = "https://api.example.com";
    private static final String COMMON_HEADER = "Authorization: Bearer token";

    public static ApiRequest createUserRequest(String body) {
        return new ApiRequest(BASE_URL + "/users", COMMON_HEADER, body);
    }

    public static ApiRequest createPostRequest(String body) {
        return new ApiRequest(BASE_URL + "/posts", COMMON_HEADER, body);
    }

    public static ApiRequest createCommentRequest(String body) {
        return new ApiRequest(BASE_URL + "/comments", COMMON_HEADER, body);
    }
}

 

정리하면, 값 세팅 로직과 주석이 가독성을 떨어뜨린 점, 그리고 공통 파라미터가 많아 팩토리 클래스를 적용하기에 적합한 상황이었다. 물론, 이런 개선이 반드시 필요하다고 생각하지는 않는다. 그 당시에는 '작은 개선이라도 해보자'는 마음이 있었던 것도 사실이다. 시간, 비용, 생산성 등 더 중요한 포인트를 잊지 않고 상황에 맞게 잘 적용하도록 주의해야 하겠다.

 

추가로 팩토리 클래스를 테스트 코드 작성 시에도 자주 활용했었는데, 이 때는 장점만큼이나 단점도 많이 느꼈다. 이 부분에 대해서는 추후 따로 포스팅할 예정이다.