가짜 중복 코드와 그 해결 방안 (With 오브젝트)

가짜 중복이란?

가짜 중복(Accidental Duplication)이란 두 개의 코드 영역이 실제로는 다른 기능을 하지만, 겉보기에는 중복처럼 보이는 상황을 의미한다. 이러한 가짜 중복을 제대로 인지하지 못하고 하나의 메서드로 묶게 되면, 서로 다른 맥락을 가진 코드가 같은 공간에 뒤섞여 있게 되어 유지보수의 복잡성이 증가하게 된다. 프로젝트를 하다보면 이런 가짜 중복코드를 진짜 중복코드로 판별하여 더 관리하기 어려운 코드를 작성하게 되는 경우가 많다.

예시 상황

어떤 통계 페이지를 만든다고 가정해보자. 이 페이지에서는 조회 시 비교 기준으로 '기준년도'와 '사업계획'이 존재합니다. 비교 기준이 무엇이든 상위 측면에서 보면 그리드와 차트를 그리는 것은 동일하다.

 

따라서 이 둘을 공통로직으로 작성한다.

 

 

AS-IS: 하나의 메서드에서 처리하는 경우

 

scwin.fn.createGridView = (searchType) => {
    // 그리드 id 생성
    
    // 그리드 헤더, Body 생성
    if (searchType == "기준년도") {
        // ...
    } else if (searchType == "사업계획") {
        // ...
    }   
    
    // 그리드 subTotal 생성
    
    // 그리드 footer 생성
    if (searchType == "기준년도") {
        // ...
    } else if (searchType == "사업계획") {
        // ...
    }   
}

 

 

이 방식의 문제점:

1. 파라미터가 여러 개 추가된다면 if (searchType == "사업계획" && isGroup == true && ...) 와 같이 복잡성이 증가한다.
2. 추후 사업계획만 수정해야 한다면, 기준년도에 대한 로직을 건드릴 위험이 있어 수정이 어려워진다.
3. 새로운 조회 기준이 추가된다면, if문 개수만큼 분기를 추가해야 하고 하나의 메서드 안에 모든 조회 기준 로직이 있어 변경의 여파를 고려해야 한다.

 

TO-BE: 해결 방안

변하지 않는 부분과 변하는 부분을 분리한다.

 

scwin.fn.createGridView = (searchType) => {
    // 공통로직
    // 1. 그리드 id 생성
    // 2. 그리드 css 설정
    // 3. 그리드 레이아웃 설정
    
    if (searchType == "기준년도") {
         ({ header, body, footer_row } = scwin.fn.getBaseYearGridViewTemplate(service, isGroup));
    } else if (searchType == "사업계획") {
        ({ header, body, footer_row } = scwin.fn.getGoalYearGridViewTemplate(service, isGroup));
    }
    
    // 공통로직
    // 4. 그리드 생성
}

scwin.fn.getBaseYearGridViewTemplate = (service, isGroup) => {
    // 그리드 헤더, 바디, 푸터 생성 후 반환
}

scwin.fn.getGoalYearGridViewTemplate = (service, isGroup) => {
    // 그리드 헤더, 바디, 푸터 생성 후 반환
}

 

 

이 방식의 장점:

1. 사업계획에 대한 수정은 getGoalYearGridViewTemplate 메서드만 수정하면 된다.
2. 기준년도에 대한 변경 여파를 신경 쓸 필요가 없다.
3. 새로운 조회 기준 추가 시 다른 기준에 대한 변경 여파를 고려하지 않아도 된다.

Java에서의 적용: 다형성 활용

Java에서는 다형성을 활용하여 이 문제를 해결할 수 있다. 다형성이란 하나의 객체에 여러 가지 타입을 대입할 수 있는 것을 말합다.

 

abstract class ComparisonRuleService {
    public void getGridView() {
        // 공통로직 실행
        
        // 추상메서드 getGridViewTemplate 호출.
    }
    
    public abstract void getGridViewTemplate();
}

class BaseYearRuleService extends ComparisonRuleService {
    @Override
    public void getGridViewTemplate() {
        // 기준년도 그리드 뷰 반환
    }
}

class GoalYearRuleService extends ComparisonRuleService {
    @Override
    public void getGridViewTemplate() {
        // 사업계획 그리드 뷰 반환
    }
}

 

 

클라이언트 코드

 

class Client {
    private final ComparisonRuleService comparisonRuleService;
        
    public Client(ComparisonRuleService service) {
        // Public 메서드 호출.
        service.getGridView();
    }   
}

 

 

이 방식을 사용하면 새로운 규칙(예: 예측년도, 평가년도)을 추가하고 싶을 때 ComparisonRuleService를 상속받는 새로운 클래스를 작성하기만 하면 됩니다. 이는 확장성을 크게 향상시킨다

이러한 형태를 템플릿 메서드 패턴이라고 한다.

결론

요구사항을 코드로 구현할 때는 최소한의 변경 가능성과 확장 가능성을 염두에 두고 코드를 작성해야 한다. 이를 통해 미래의 변경사항에 더 유연하게 대응할 수 있고, 코드의 유지보수성을 크게 향상시킬 수 있다.