[Issue Tracker Project] Switch - Case Refactoring

출처) 짤봇 - https://jjalbot.com/jjals/D1PYZTxcX

 

 

 

기록 이유

이슈 내의 Milestone, Label, Assignee 를 수정하는 updateIssueRelated() 메서드에 Switch - Case 문 떡칠을 리팩토링하고 팀원인 검봉에게 공유하는 것을 깜빡하지 않기 위해 기록하게 되었다 🙂 기록 시작 ~

 

 

 

리팩토링이 필요한 로직

클라이언트에서 요청한 Issue 아이디, 어떤 것을 수정할 지 결정하는 Type, 해당 Type 의 아이디를 지닌 DTO 를 사용해서 Swith - Case 분기문을 통해 Type 을 확인한 뒤, Isse 아이디에 맞는 Issue Entity 를 수정하는 로직이다. 엄청 복잡한 로직은 아니지만 분기문을 IssueService 클래스에서 없애기 위해 인터페이스 추출 기법을 활용한 리팩토링을 시도해보았다.

 

Switch - Case 로 점철된 updateIssueRelated() 메서드

 

 

 

---

 

 

 

 

리팩토링 시작

먼저 전체적인 구성을 한 눈에 알아보자.

 

1. RelatedUpdateFactory

  - 타입을 받아 알맞은 Related 클래스를 생성하는 역할

 

2. RelatedUpdatalbe Integerface

  - 알맞은 Related 클래스가 생성되었다면, 해당 Issue 에 타입 내용을 수정하는 역할

 

전체적인 인터페이스 및 구현 클래스 구성

 

 

 

수정할 타입이 Milestone 인지 Label 인지 Assignee 인지에 따라 알맞은 클래스가 생성되어 기존 Issue 의 타입을 수정하는 방식으로 인터페이스 추출을 해보자.

SimpleRelatedUpdateFactory 클래스는 RelatedUpdateFactory 인터페이스를 상속받아 getRelatedType() 메서드를 구현한다.

getRelatedType() 메서드는 클라이언트가 요청한 타입을 받아 분기로 판단한 후 알맞는 클래스를 생성할 것이다.

각 Repository 는 타입에 따라 기존 Issue 의 타입을 수정하는 로직에서 사용하기 때문에 클래스 생성 시 인자로 넘겨줬다.

 

RelatedUpdateFactory 인터페이스와 구현체인 SimpleRelatedUpdateFactory 클래스

 

 

 

그리고 RelatedUpdatable 을 구현한 각 타입 의 구현 클래스에서 판단된 타입에 따라 Issue 를 다시 수정하도록 로직을 짜주자.

getRelatedType() 메서드의 결과로 알맞은 Related 클래스가 생성돼서 해당 Issue 의 타입 내용을 수정할 수 있을 것이다.

 

RelatedUpdatable 인터페이스와 구현체인 각 Related 클래스

 

 

 

 

이제 updateIssueRelated() 메서드를 확인해보면 ?

Swith - Case 문을 사용했을 때 보다 훨씬 깔끔해진 모습을 볼 수 있다 !

 

리팩터링 후 updateIssueRelated() 메서드