[DISCUSSION] 소셜로그인에서의 OCP 활용

[ffalswo2]

의성형의 아이디어로 시작된 리팩토링 과정과 그 결과와 장점을 공유합니다.

기존의 코드

초기구현 코드의 모습은 아래와 같습니다.

func transform(input: LoginViewModelInput) -> LoginViewModelOutput {
        let loginResult = input.loginButtonTapped
            .flatMap { loginType -> AnyPublisher<(type: LoginType, state: LoginState), Never> in
                return loginType == .kakao
                ? self.makeKakaoFuture()
                : self.makeAppleFuture()
       ....
}

func makeKakaoFuture() -> AnyPublisher<(type: LoginType, state: LoadingState), Never> {
  return Future<(type: LoginType, state: LoadingState), NetworkError> { promise in
      Task {
          do {
              // ✅ 여기서부터
              let kakaoToken = try await self.loginKakaoWithApp()
              try await self.manager.login(type: .kakao, token: kakaoToken)
              self.navigator.loginButtonTapped(type: .loginSuccess)
              promise(.success((type: .kakao, state: .end)))
              // ✅ 여기까지
          }.catch { error in
              return Just((type: .kakao, state: .error(message: "카카오 로그인 실패")))
          }
          ...
}

func makeAppleFuture() -> AnyPublisher<(type: LoginType, state: LoadingState), Never> {
  return Future<(type: LoginType, state: LoadingState), NetworkError> { promise in
      Task {
          do {
              // ✅ 여기서부터
              let appleToken = try await self.loginApple()
              try await self.manager.login(type: .apple, token: appleToken)
              self.navigator.loginButtonTapped(type: .loginSuccess)
              promise(.success((type: .apple, state: .end)))
              // ✅ 여기까지
          }.catch { error in
              return Just((type: .apple, state: .error(message: "애플 로그인 실패")))
          }
          ...
}

각 소셜로그인에 해당하는 메서드에서 체크표시를 통해 표시한 메서들에 들어가는 인자값(어떤 소셜로그인인지에 대한 type값)만 바뀌고, 큰 과정은 완전히 동일하다는 점을 알 수 있습니다.

그 과정을 코드레벨 단위로 요약하면 아래와 같습니다.

1. 소셜로그인 access token을 받는다. (토큰을 받는 행위)
2. 1번에서 구한 token과 어떤 로그인 타입인지를 자체 서버API호출을 위해 manager의 login메서드값의 인자로 담아 login메서드를 호출한다.
3. 에러가 발생한다면 해당 로그인이 실패했다는 에러 메시지를 보낸다.

이는 모든 소셜로그인이 공통으로 가지고 있는 로직입니다.

공통되는 프로퍼티 메서드 추상화

이를 토대로 아래와 같은 interface를 구성할 수 있습니다.

protocol SocialLogin {
    var type: LoginType { get set }
    var errorMessage: String { get set }

    func getToken() async throws -> String
}

getToken, type, errorMessage의 경우 어떤 소셜로그인이던 필요한 값들이기 때문에 추상화할 수 있습니다. 하지만 실제로 어떤 값과 메서드 구현부를 가질지는 해당 protocol을 채택한 객체에 따라 다릅니다. Plu에서는 카카오와 애플 소셜로그인이 존재하기에 아래와 같이 객체를 만들 수 있습니다.

struct Kakao: SocialLogin {
    var type: LoginType = .kakao
    
    var errorMessage: String = "카카오 로그인 오류"
    
    func getToken() async throws -> String {
        return try await loginKakaoWithApp()
    }
    
    private func loginKakaoWithApp() async throws -> String {
        // login 로직
        return "kakao app token"
    }
    
    private func loginKakaoWithWeb() async throws -> String {
        return "kakao web token"
    }
}

struct Apple: SocialLogin {
    var type: LoginType = .apple
    
    var errorMessage: String = "애플 로그인 실패" 
    
    func getToken() async throws -> String {
        return try await loginApple()
    }
    
    private func loginApple() async throws -> String {
        // Apple 로직
        return "apple token"
    }
}

Kakao와 Apple 객체는 SocialLogin protocol로 묶일 수 있고, 소셜로그인을 위해 필요한 모든 값과 메서드는 SocialLogin protocol에 정의되어있기 때문에 호출부에서 실제로 어떤 객체가 들어오는지에 상관없이 필요한 값을 요청할 수 있게 됩니다.

이를 코드에 적용하면 아래와 같이 바뀌게됩니다.

리팩토링 후

func transform(input: LoginViewModelInput) -> LoginViewModelOutput {
    let loginResult = input.loginButtonTapped
        .flatMap { loginType -> AnyPublisher<(type: LoginType, state: LoadingState), Never> in
            self.makeSocialLoginFuture(socialLogin: loginType.object)
        }
        .eraseToAnyPublisher()
    
    return LoginViewModelOutput(loginResult: loginResult)
}

@MainActor
func makeSocialLoginFuture(socialLogin: SocialLogin) -> AnyPublisher<(type: LoginType, state: LoadingState), Never> {
    return Future<(type: LoginType, state: LoadingState), NetworkError> { promise in
        Task {
            do {
                let token = try await socialLogin.getToken()
                try await self.manager.login(type: socialLogin.type, token: token)
                self.navigator.loginButtonTapped(type: .loginSuccess)
                promise(.success((type: socialLogin.type, state: .end)))
            } catch {
                promise(.failure(error as! NetworkError))
            }
        }
    }.catch { error in
        return Just((type: socialLogin.type, state: .error(message: socialLogin.errorMessage)))
    }
    .eraseToAnyPublisher()
}

makeFuture 메서드의 인자로 SocialLogin protocol을 채택한 객체를 받습니다. 이를 통해서 protocol에 정의해둔 프로퍼티와 메서드를 통해서 공통되는 로직들에 대한 요청을 보낼 수 있게 되어 각 소셜로그인별로 나눠진 메서드가 하나로 합쳐지게 되고 중복되는 구현들이 없어지게 되었습니다.

또한 Open-Closed Principle(OCP) 원칙을 통해 훨씬 유연한 코드를 얻게 되었습니다.

만약 추후에 네이버 소셜로그인이 추가되었다고 가정해보겠습니다.
그 때 단순히 우리가 할일은 SocialLogin protocol을 채택한 Naver 구조체를 정의해주고 필요한 곳에 Naver 소셜로그인 객체를 넣어주기만 하면 런타임시에 실제 구현체를 바라보게 됩니다. 즉, 기존의 코드를 수정하지 않고도 기능을 추가할 수 있게 됩니다. Naver 구조체는 아래와 같은 모습이 될 것 입니다.

struct Naver: SocialLogin {
    var type: LoginType = .naver
    
    var errorMessage: String = "네이버 로그인 실패" 
    
    func getToken() async throws -> String {
        return try await loginNaver()
    }
    
    private func loginNaver() async throws -> String {
        return "naver token"
    }
}

Login protocol을 통한 기본 구현 제공

로그인이 로그인 화면에서뿐만 아니라 마이페이지 등과 같은 다른 화면에서도 로그인이 가능하게 될 상황도 고려하였습니다.
다른 화면에서 로그인 과정이 이루어진다고 해도 사실 위의 로직이 바뀔 일은 없기에 Login protocol을 채택만 하면 기본 구현된 로그인 로직을 사용할 수 있도록 구성하였습니다.

protocol Login: AnyObject {
    var manager: LoginManager { get set }
    var navigator: LoginNavigation { get set }
    func makeSocialLoginFuture(socialLogin: SocialLogin) -> AnyPublisher<(type: LoginType, state: LoadingState), Never>
}

extension Login {
    @MainActor
    func makeSocialLoginFuture(socialLogin: SocialLogin) -> AnyPublisher<(type: LoginType, state: LoadingState), Never> {
        return Future<(type: LoginType, state: LoadingState), NetworkError> { promise in
            ...위와 동일한 구현체...
    }
}

만약 예시 상황 그대로 마이페이지에 로그인 기능이 추가된다고 하더라도 MyPageViewModel에 Login protocol을 채택시키고 MyPageNavigation에 LoginNavigation protocol을 추가로 채택하는 것 만으로 로그인 기능을 사용할 수 있습니다.

정리

공통의 기능을 묶을 수 있는 여지가 보인다면 protocol을 통해 이를 묶고 OCP를 고려해볼 수 있을 것 같습니다. 하지만 소셜로그인과 같이 명확히 공통의 기능이 묶이는 경우가 더 있을지 모르겠지만 코드를 작성할 때 위와 같은 시선을 가지고 개발한다면 조금 더 확장성 있고 유연한 코드를 작성할 수 있을 것 같습니다.

[kimscastle]

추가적인 제안

self.navigator.loginButtonTapped(type: .loginSuccess)

사실 제가 찜찜했던부분이 이게 pure function이 아니어서 그런거였는데
makeSocialLoginFuture의 인자로 LoginNavigation interface타입의 변수를 받으면 함수자체가 side effect없는 순수함수로 동작할 수 있을거같아요

한번 수정해보시고 적용해보는건 어떨까요?
아무래도 해당 방식은 navigation이 프로토콜의 변수라 var로 선언되어있어서(let이라면 변하지않아서 지금처럼써도 pure function입니당) side effect를 막기위해서 변수로 받아 독립적으로 동작하는걸보장하는게 좋을거같아요

---

open combine을 뜯어본 경험이 이렇게 아이디어를 주고 코드를 바라보는 눈을 바꿔줄줄은 몰랐네요
어제 저도 이야기하다가 문득 open combine의 upstream을 타고들어가본 생각이 떠올라서 이렇게 제안드린건데

분명히 비슷한 함순데 구현부가 달라서 하나로 묶지못했던 경험이 가끔있었던거같아요
그럴떄마다 이렇게 interface와 OCP를 활용한 방식으로도 리팩터링이 가능한지 고민해보면 좋은 답을 얻을 수 있을거같네요