[Jed] Step1 - 로그인 화면 구현, 네트워크 통신 구현 관련 리팩토링

[junu0516]

작업 내용

• LoginView 내부에서 값의 유효성 판단하던 로직을 LoginViewController로 이동
• HttpRequestHandler의 요청 보내는 메소드 내부에서 오류 발생 시 로그 찍던 부분 모두 제거
• HttpRequestHandler의 요청 보내는 메소드가, 요청 처리 및 디코딩을 모두 수행하던 것을 모두 분리

학습 키워드

• Result Type
• URLSession
• Enum associated value

고민과 해결

이번 리팩토링에서는 직전 피드백에서 언급해주신 로그인 뷰에서 입력값의 유효성을 판단하는 부분을 컨트롤러로 이동 하는 것과 Http요청을 처리하는 메소드에서 요청 생성 및 응답수신, 디코딩 등을 모두 수행하는 것을 분리 하는 부분을 수정했습니다.

1. LoginView에서 입력값 검증하는 로직 분리

• 로그인 뷰의 텍스트필드에 입력값이 들어오면, 우선 이를 모두 컨트롤러로 넘겨서 유효 여부를 판단 후 로그인 버튼의 활성화를 컨트롤러가 결정하도록 했습니다.
• 따라서 기존 LoginView의 입력값 판단하던 메소드를 모두 LoginViewController로 넘겨서 delegate method로 호출하도록 했습니다.

2. HttpRequestHandler 내부의 요청 처리 메소드의 여러 책임 분산

• 기존에 지적해주신대로 다시 확인해보니 HttpRequestHandler의 sendReqeust 메소드 내부에서 요청 객체(URLRequest)의 생성 , 응답에 대한 처리 , 응답 데이터 디코딩 의 동작을 모두 수행하고 있었습니다.
• 우선 언급한 세 가지 책임을 각기 별도의 메소드에서 수행하도록 수정해야 겠다고 판단했습니다.

2-1. 요청 객체 생성 책임 분리

• 요청 객체(URLRequest)의 생성 의 경우 generateURLRequest 라는 메소드를 호출하여, 이것이 리턴하는 객체를 sendRequest에서 사용하도록 했습니다.

2-2. 오류 발생에 대한 처리 분리

• 응답에 대한 처리 부분에서, 기존에 말씀하신 오류 발생 시 로그를 찍던 부분을 모두 제거했습니다.
• 오류가 발생하면 이에 대한 별도의 메소드 호출을 통해 로그 외의 방법으로 직접 확인할 수 있어야 한다고 생각했고, 우선 오류 발생시 화면에 Alert가 나타나도록 했습니다.
• 성공/실패 에 대한 각각의 처리는 Result<Data,Error> 타입을 사용할 경우 성공과 실패의 두 가지 케이스로만 활용 가능하기 때문에 해당 타입을 파라미터로 받는 handleResponse 라는 메소드를 선언한 후 내부의 switch문에서 .success, .failrue에 따라 각기 다른 로직을 처리하도록 했습니다.
• 성공/실패에 따른 로직 처리는 HttpResponseHandleable 이라는 프로토콜을 선언하여, LoginViewController가 이를 채택하도록 하고 sendRequest() 호출 시에 추상 타입으로 뷰컨트롤러의 참조를 넘겨서, 이후 handleResponse 호출 시에 프로토콜을 채택하면서 구현한 메소드(handleSuccess, handleFailrue)을 호출하도록 했습니다.