리소스 리팩토링(디렉토리 구조 및 클래스 생성및 서비스 구조 변경)

기존에 작성된 회사 리소스가 통일성 이 너무 떨어지는 관계로 리팩토링을 진행 할려고 한다.

 

 

일단 기존 리소스의 문제점을  파악해보면  크게 3가지 문제를 찾았고 이를 수정하고자 한다.

 

1. 생성자 문제(통일되지 않은 방식)

/** 
*	현재 사용중인 생성하는 방법은 레거시 포함 총 4가지 사용중이다
*	1. 정적 팩토리 메서드
*	2. 자바 빈즈
*	3. 심플 빌더 패턴
*	4. 점층적 생성자 패턴
**/

 

• 정적 팩토리 메서드 예시

public class CreationTest {
    private String id;
    private String desc;
    private String desc2;
    private String desc3;

    private String desc4;

    private String desc5;

    private String desc6;

    private CreationTest(String id, String desc, String desc2, String desc3, String desc4,
            String desc5,
            String desc6) {
        this.id = id;
        this.desc = desc;
        this.desc2 = desc2;
        this.desc3 = desc3;
        this.desc4 = desc4;
        this.desc5 = desc5;
        this.desc6 = desc6;
    }

    public static CreationTest of(String id, String desc, String desc2, String desc3, String desc4,
            String desc5,
            String desc6) {
        return new CreationTest(id, desc, desc2, desc3
                , desc4, desc5, desc6);

    }

 

 

사용하면서 문제점 

• 사용 할 수록 파라메터 수에 따라 만드는 것이 부담 되고 추가로 할당 시  해당 파라메터명이 확인이되지만(인텔리제이의 경우 확인 가능) 가독성이 너무 떨어진다.

 

자바 빈즈 예시

 

public class CreationTest {
    private String id;
    private String desc;
    private String desc2;
    private String desc3;

    private String desc4;

    private String desc5;

    private String desc6;

	
    
      public CreationTest(String id, String desc, String desc2, String desc3, String desc4,
            String desc5,
            String desc6) {
        this.id = id;
        this.desc = desc;
        this.desc2 = desc2;
        this.desc3 = desc3;
        this.desc4 = desc4;
        this.desc5 = desc5;
        this.desc6 = desc6;
    }


    public void setId(String id) {
        this.id = id;
    }

    public void setDesc(String desc) {
        this.desc = desc;
    }

    public void setDesc2(String desc2) {
        this.desc2 = desc2;
    }

    public void setDesc3(String desc3) {
        this.desc3 = desc3;
    }

    public void setDesc4(String desc4) {
        this.desc4 = desc4;
    }

    public void setDesc5(String desc5) {
        this.desc5 = desc5;
    }

    public void setDesc6(String desc6) {
        this.desc6 = desc6;
    }

    public String getId() {
        return id;
    }

    public String getDesc() {
        return desc;
    }

    public String getDesc2() {
        return desc2;
    }

    public String getDesc3() {
        return desc3;
    }

    public String getDesc4() {
        return desc4;
    }

    public String getDesc5() {
        return desc5;
    }

    public String getDesc6() {
        return desc6;
    }
}

 

사용하면서 문제점

• 공부할 때 처음 배우게 되는 생성자이며 
• 객체의 일관성이 보장되지 않고, 불변성 유지가 되지 않는다. 
• 또 객체를 완성하기위해 메서드를 지속적으로 호출..

 

점층적 생성자 예시

public class CreationTest {
    //필수
    private final String id;
    private final String desc;

    //선택
    private final String desc2;
    private final String desc3;
    private final String desc4;
    private final String desc5;
    private final String desc6;
    
    // 필수 매개변수를 가지는 생성자
    public CreationTest(String id, String desc) {
        this(id, desc , null, null, null, null, null);
    }
    
//    //필수 + 선택
    public CreationTest(String id, String desc, String desc2) {
        this(id, desc , desc2, null, null, null, null);
    }
    
    //ALL
    public CreationTest(String id, String desc, String desc2, String desc3, String desc4,
            String desc5,
            String desc6) {
        this.id = id;
        this.desc = desc;
        this.desc2 = desc2;
        this.desc3 = desc3;
        this.desc4 = desc4;
        this.desc5 = desc5;
        this.desc6 = desc6;
    }

 

사용하면서 문제점

생성자의 수가 많아지면 클래스가 복잡해짐

정적 팩토리 메서드와 동일하게 해당 생성자만 보고 파악이 어려움

 

빌더(심플 빌더패턴) 예시 (실제 구현 시에는 lombok을 통해 구현 예정)

public class CreationTest {

    private String id;
    private String desc;
    private String desc2;
    private String desc3;
    private String desc4;
    private String desc5;
    private String desc6;

    public CreationTest(Builder builder) {
        this.id = builder.id;
        this.desc = builder.desc;
        this.desc2 = builder.desc2;
        this.desc3 = builder.desc3;
        this.desc4 = builder.desc4;
        this.desc5 = builder.desc5;
        this.desc6 = builder.desc6;
    }

    public static class Builder {
        private String id;
        private String desc;
        private String desc2;
        private String desc3;
        private String desc4;
        private String desc5;
        private String desc6;

        // 필수적인 필드 : brand
        public Builder(String id, String desc) {
            this.id = id;
            this.desc = desc;
        }
        public Builder desc2(String desc2) {
            this.desc2 = desc2;
            return this;
        }
        public Builder desc3(String desc3) {
            this.desc3 = desc3;
            return this;
        }
        public Builder desc4(String desc4) {
            this.desc4 = desc4;
            return this;
        }
        public Builder desc5(String desc5) {
            this.desc5 = desc5;
            return this;
        }
        public Builder desc6(String desc6) {
            this.desc6 = desc6;
            return this;
        }

        public CreationTest build() {
            return new CreationTest(this);
        }
    }
}

 

사용하면서 문제점

• 관리해야할 클래스 코드 가 많아짐

 

 

해결 방안

위와 같이 통일되지 않은 구조로 사용중이라 한가지 패턴을 지정할때  심플 빌더 패턴을 적용할 예정이다.

외부 연동 시에도 많은 파라메터와 계층형 구조로 인해  정정 팩토리 메서드라던지 점층적 생성자 패턴은 파라메터 파악이 
어렵기 떄문에

 

 

---

2.  디렉토리 구조 

현재 실제 리팩토링 예정인 리소스 구조(해당 리소스는 외부 API 연동을 담당하는 리소스 이다)

 

현재 문제점

root 에서 controller, service,  repository 등 으로  바로 내려가는 구조이다 보니  코드 가독성도 떨어지고,  조잡한 느낌이 많이 들었다.

 

 

해결 방안 

2가지 안으로 생각중이다.

1안

 

이 1안의 경우 실제로  외부 연동 해서 데이터를 처리할때 도메인 단위로 분리하여 

재고 처리 , 주문 처리, 배송 추적 처리를 분리하는 방안이다.

 

 

2안

 

 

내가 원하는 방향은 2안 처럼 업체별인 아닌 주문, 배송 추적, 재고 관리 도메인 영역별로 변경을 하고 싶지만, 이미 이전에 쿠팡이라는 업체로 묶은 부분이 있다보니  내 의견대로 진행이 될지는 모르곘다.

 

기존 보다는  1안, 2안 모두 개선은 가능하다보니 시간이 조금 부족하다면

 

---

3. 서비스 순환 참조 문제

 

정확하게는 일어날 여지가 있다보니  리팩토링 진행하는 과정에서 수정을 할려고 한다. 

 

2번 디렉토리 구조를 완성하면  해당 정면이 되는 파사드 인터페이스 를 통해   대표 서비스 클래스 

하위로  해당 로직 서비스를 붙이고  로직 서비스 끼리는 서로 서비스를 주입받지 않고 사용하는 방향으로 생각중이다.

 

글로만 설명이 어려우니

draw io 를 통해 간략하게 그려봤다.

 

 

클라이언트 에서 호출하여 앱서비스에서 하위 로직 서비스를 개별로 호출하도록 처리하며  하위 service1,2,3 의 경우  서비스를 참조하지 않도록 만들어야한다.

---

 

4. 테스트코드 

현재 작성된 테스트 코드들  또한 방식이 일정하지 않고 필요한 부분들이 작성되지 않은 부분들이 있어 이런 부분들 또한 코드 및 패키지 리팩토링에 따라 수정을 진행할 예정이다.

(테스트 코드는 이전에 읽었던 책을 다시 정리하여 재정리 예정)