[TIL] 20231129

Protocol을 활용한 추상화 (코드 리팩토링)

이번주 새싹 과제에서 PR을 올린 후에 아이디어가 떠올라 어제 프로토콜 더 잘쓰기!! 에 대한 내용을 어제 정리했는데, 해당 내용을 적용해서 오늘 코드 리팩토링을 해봤다.

주요 변경 사항

protocol extension 을 활용한 메서드 기본 구현

Playable 프로토콜 extension을 통해 공통적으로 사용되는 메서드를 기본 구현해 추상화했습니다.

• validateUserInput() - 사용자 입력 값 유효성 검사 메서드
  • 사용자 입력 값 유효성 검사 로직의 경우 가위바위보, 묵찌빠 두 게임에서 동일하기 때문에 extension에 기본 구현함으로써 각 클래스 내에서 같은 기능을 하는 함수를 구현하지 않아도 되도록 해서 중복된 코드를 하나로 묶었습니다.
• judgeWinner() - 게임의 승자를 리턴하는 메서드
  • 게임의 승자를 리턴하는 로직이 묵찌빠 클래스에서 반복되어 메서드화 해주었고, 기본 구현을 통해 클래스 내 함수 호출을 통해 해당 기능을 바로 사용할 수 있도록 했습니다.
  • 이 메서드의 경우 승자를 판단하는 로직이 두 게임에서 동일하긴 하지만, 현재는 묵찌빠 클래스에서만 사용되어 해당 함수의 위치를 묵찌빠 클래스로 옮겨도 좋을 것 같습니다. (확장성을 대비한다면 프로토콜 익스텐션 내 기본구현이 더 좋을 것 같기도 함)

<기존 코드>

// 가위바위보 클래스
final class RockPaperScissorsManager: Playable {

    func validateUserInput(_ input: String?) throws -> RockPaperScissorsType {
        guard let input else {
            throw RockPaperScissorsError.invalidInput
        }

        switch input {
        case "0": return .none
        case "1": return .scissors
        case "2": return .rock
        case "3": return .paper
        default: throw RockPaperScissorsError.invalidInput
        }
    }
}

// 묵찌빠 클래스
final class AdvancedRockPaperScissorsManager: Playable {

    func validateUserInput(_ input: String?) throws -> RockPaperScissorsType {
        guard let input else {
            throw GameError.invalidInput
        }

        switch input {
        case "0": return .none
        case "1": return .rock
        case "2": return .scissors
        case "3": return .paper
        default: throw GameError.invalidInput
        }
    }
}

 

두 클래스 내 함수가 굉장히 비슷하다.. 사용자 입력 값인 1, 2, 3 이 의미하는게 달라서 특정 케이스에서 리턴하는 케이스만 조금 다름!!!

그런데 이걸 두 번 구현해?!??!!??! 생각이 들었음

protocol extension 내 기본 구현을 통해 이 문제를 해결했다!

 

extension Playable {

    func validateUserInput(_ input: String?) throws -> Int {
        guard let input = input,
              let num = Int(input),
              (0...3).contains(num) else {
            throw GameError.invalidInput
        }

        return num
    }

    func judgeWinner(_ gameResult: GameResultType) -> PlayerType {
        return gameResult == .win ? .user : .computer
    }
}

 

이렇게 구현해두면 각 클래스 내에서 따로 구현하지 않아도 함수 호출을 하면 이렇게 기본 구현해둔 메서드가 호출된다.

프로토콜 익스텐션 내 기본 구현을 통해 공통된 부분을 묶어 추상화할 수 있는 것!!!

승자 판단 로직도 같은 코드가 좀 반복되길래 그냥 메서드화 시켜서 얘도 extension 내에 정의해줬다.

PR 코멘트에 남겼듯이 지금은 한 클래스에서만 사용되어서 굳이 여기다가 구현안하구 사용하는 클래스에만 구현해도 될 것 같다 ㅎ…. 확장성을 위해 어쩌구…이렇게 적긴 했지만.. ㅎ…ㅎ…

associatedtype 활용

프로토콜 내에서 제네릭의 역할을 하는 associatedtype을 활용했습니다.

• judgeGame() 함수의 파라미터로 넘겨주는 타입(묵찌빠 타입, 가위바위보 타입)을 각 클래스에서 다르게 사용하기 위해 associatedtype을 활용했습니다. (다형성 측면에서의 장점이 있다고 생각함)
• 기존에는 RockPaperScissorsType 을 재활용하는 방식으로 기능을 구현했지만 직관적인 코드를 위해 AdvancedRockPaperScissorsType 을 생성해주었습니다.
• 두 개의 타입(RockPaperScissorsType, AdvancedRockPaperScissorsType)의 구조가 같아 기존 코드도 로직상 문제는 없었지만, 각 클래스에 해당하는 타입을 사용할 수 있도록 해 역할을 명확히 하고 코드 가독성을 높였습니다.

// 기존 코드 파라미터 타입 RockPaperScissorsType -> AdvancedRockPaperScissorsType 변경
func judgeGame(user: AdvancedRockPaperScissorsType?,
                   computer: AdvancedRockPaperScissorsType?,
                   turn: PlayerType) -> GameResultType {
        if user == AdvancedRockPaperScissorsType.none {
            return .exit
        }

        if user != computer {
            return .draw
        }

        return turn == .user ? .win : .lose
    }
}

 

PR 코멘트에 써둔 것 처럼 판단 로직상에는 문제가 없지만 사실 묵찌빠 클래스에서는 묵찌빠 타입으로 판별을 해주는게 맞지 않나?!?!?

라는 생각이 들어 associatedtype을 활용함!!! 가위바위보 클래스에서는 가위바위보 타입으로 판별하고, 묵찌빠 클래스에서는 묵찌빠 타입으로 판별해서 더 직관적인 코드를 작성할 수 있었고, 클래스별 역할을 명확히 했다.

타입 변환을 위한 Convertible 프로토콜 생성

• 묵찌빠 게임 내에서 패가 다를 경우 가위바위보 게임의 결과로 판단해주어야 하는 로직이 있어서 가위바위보.judgeGame() 을 호출해야 하는데, 이때 묵찌빠 enum 타입의 값을 가위바위보 enum 타입으로 바꿔서 넘겨주기 위한 변환 로직에서 Convertible 프로토콜을 활용했습니다.
• 확장성을 위해 Convertible 프로토콜 내에서도 type 부분을 associatedtype으로 선언해주었습니다.

<기존 코드>

@frozen
enum RockPaperScissorsType: Int {
    case none = 0
    case scissors = 1
    case rock = 2
    case paper = 3

    func getAdvancedType() -> RockPaperScissorsType {
        switch self {
        case .none:
            return .none
        case .scissors:
            return .rock
        case .rock:
            return .scissors
        case .paper:
            return .paper
        }
    }
}

 

<변경한 코드>

protocol Convertible {
    associatedtype T
    
    var convertedType: T { get }
}

enum AdvancedRockPaperScissorsType: Int, Convertible {
    case none = 0
    case rock = 1
    case scissors = 2
    case paper = 3
    
    typealias T = RockPaperScissorsType
    
    var convertedType: T {
        switch self {
        case .none:
            return .none
        case .rock:
            return .rock
        case .scissors:
            return .scissors
        case .paper:
            return .paper
        }
    }
}

 

기존 코드랑 딱히 바뀐게 없다? 라고 느낄 수 있는데,,,

각 케이스에 매칭되는 타입으로 변환해주는 방식으로 바뀌어서 조금 더 개선된 것 같긴하다..

리뷰에 ISP에 대한 내용을 언급해주셨는데 리뷰어님 의견에 완전 동의해서 솔리드 제대로 정리해봐야겠다!!!!