Logic 분리하기

# Logic 분리하기

우선 Add와 Edit기능을 하는 AddEditTaskFragment에서 작동하는 로직을 분석해보자.

간단하게 표현하면

1. 사용자에게 Task 정보를 입력받는다.
2. 입력 받은 정보를 Task 오브젝트로 만든다.
3. 생성된 오브젝트를 DB에 추가한다.

3단계로 표현할 수 있다. 여기서 Edit인 경우는 기존 Task를 불러오는 선행작업이 추가된다.

# 각 Logic을 처리해야하는 곳을 생각해보자.

1번은 사용자가 View에 입력값을 입력하는 상황이다.
View를 다루는 Fragment가 이 로직을 처리하기 적합한 위치일 것이다.

 

2번은 View에 입력된 값을 취합하여 Task 오브젝트로 만드는 일이다.
View의 값을 읽기 위해서는 EditText 등 입력에 관여하는 View를 사용해야하므로 Fragment에서 처리한다.

 

3번은 Object를 DB에 인서트하는 일으로 View가 전혀 개입될 여지가 없으므로 VIewModel에서 처리한다.

 

아래는 각 로직의 처리 상황을 그림으로 표현해본 것이다.

# Fragment가 너무 하는 일이 많다.

코드를 작성하기 보니 Fragment의 코드가 너무 비대하고 ViewModel은 하는 일이 거의 없다.

 

View에 입력된 값을 오브젝트로 만들어서 데이터베이스에 추가하는 간단한 작업이므로 ViewModel이 담당할 로직이 적을수도 있지만 최대한 View를 멍청하게 남겨두기 위해서 리팩토링을 진행해보자.

 

다시 살펴볼 로직은 2번에 해당하는 입력값을 Task Object로 포장하는 작업이다.

 

처음 코드를 작성할 때는 View의 값을 읽어오는 작업이므로 View 안에 로직을 작성했다.

하지만 자세히 분리를 하자면 View의 값을 읽는 작업과 값을 Task Object로 포장하는 2가지 작업으로 나눌 수 있다.

첫번째는 View에 도움이 필요한 작업이지만 두번째는 View의 역할 없이도 할 수 있는 작업이다.

 

즉 이 부분을 ViewModel이 담당하게 되면 View의 역할을 더 줄이고 바보로 남겨둘 수 있다.

이는 차후에 View의 교체나 유지보수를 쉽게 할 수 있도록 도와줄 것이다.

# ViewModel이 더 많은 일을 하도록 수정하자.

로직을 ViewModel로 옮기기 위해서는 View의 입력값을 ViewModel로 전송해주는 로직이 추가되어야한다.

그리고 입력값을 ViewModel이 보관하고 있어야한다.

각 View의 값을 홀딩할 LiveData를 추가하고 View는 입력값을 LiveData에 전송해서 저장해둔다.

그리고 저장 버튼이 클릭 됐을 때 ViewModel은 View의 도움 없이 보관하고 있던 LiveData의 값을 참조하여 Task Object를 생성할 수 있다.

 

 

이제 View가 담당하는 역할은 사용자에게 값을 입력 받는 역할 그리고 입력 받은 값을 ViewModel에 저장시키는 역할이다.

 

Edit mode에서는 역으로 기존 Task Object를 읽어와서 View에 업데이트하는 로직이 필요한데.

ViewModel의 LiveData가 View에 업데이트할 모든 정보를 보관하고 있고 View는 옵저버를 통해서 자동으로 LiveData의 값을 업데이트 시킨다.

# Summary

사실 Fragment의 코드라인 수가 너무 많아서 리팩토링을 시작했다.

자세히 살펴보니 Task Object를 생성해내는 과정을 ViewModel로 옮길 수 있겠다는 생각을 했고 ViewModel로 로직을 이동시켰다.

 

하지만 바뀐 로직을 실행하기 위해서 Fragment에는 LiveData로 데이터를 전송하고 옵저버를 추가하는 새로운 코드가 생겼고, ViewModel에는 이전보다 더 많은 양의 새로운 코드가 추가 되었다.

 

코드라인을 줄이려고 시작한 작업이었지만 결과물을 살펴보면 Fragment의 코드 수는 거의 차이가 없었고
ViewModel은 대폭 증가한 셈이다.

 

하지만 로직을 그림으로 그려보면 확실하게 View가 담당하는 역할이 축소되었음을 알 수 있다.

 

리팩토링 이전에도 View가 하던 로직이 복잡한 로직은 아니다. 입력값을 읽어서 object를 만드는 간단한 작업이니까.

파일의 코드 수를 줄이기 위해서는 리팩토링 전의 코드가 더 최적화 상태라고 볼 수도 있을 것 같다.

 

수정 이전과 이후 어떤 버전이 더 나은 코드인지는 모르겠지만
일단 기존 View의 일부분을 ViewModel로 이동시켰다는 점에서 개인적으로는 만족스러운 리팩토링이었다.

 

ViewModel에게 많은 일을 시키고 View는 가볍게 두는 것.
튜토리얼 글에서 많이 강조하는 문장인데 스스로 코드를 작성하면서 적용해보니까 한걸음 더 이해가 된것 같다.