[헤드퍼스트 디자인패턴 with Swift] - 1. 전략 패턴(Strategy Pattern)

 

🔥 헤드퍼스트 디자인패턴 시작하기

"헤드퍼스트 디자인패턴"은 Java를 기반으로 쓰인 책이지만, 여기서는 Swift로 구현하며 내용을 정리해 볼게요!
항상 그렇지만 이 글은 개인적인 정리의 목적으로 작성하는 것이기 때문에 책을 직접 읽어보기를 추천드려요 :]

 

🐥 오리 시뮬레이션 게임 만들기

SimUDuck이라는 오리 게임을 만들어볼게요 :]

 

 

방법 1. 일반적인 상속 구조 사용하기

일반적인 표준 객체지향 기법을 사용하여 Duck이라는 Super class를 만들고, 상속을 통해 여러 오리를 만들어요.

(private, final 등 세세한 설정 등은 생략할게요)

각 오리들은 부모 클래스(Duck)의 메서드를 override 하여 사용해요.

 

 

🚨 추가 요구 사항 발생

➡️ 오리는 날 수 있어야 합니다

 

여기서 Duck 클래스에 fly 메서드를 추가해요.

 

이렇게 되면 모든 오리에 하늘을 나는 기능이 추가돼요.

문제는 오리 중에 장난감 오리처럼 하늘을 날 수 없는 오리가 있다는 거예요 🥲

이 문제를 단편적으로 해결하기 위해서는 날지 못하는 오리에서 fly를 override 하여 아무 동작도 하지 않게 만들 수 있어요.

 

하지만 여기서 다른 문제가 발생해요.

 

🚨 추가 요구 사항 발생

➡️ 앞으로 6개월마다 제품을 업데이트하기로 결정

 

이렇게 상속을 사용하는 상황에서 제품 스펙이 지속적으로 업데이트된다면 유지 보수에 큰 리소스가 들어가요.

모든 Duck의 메서드들을 전부 살펴보면서 상황에 따라 변경해야 해요.

 

방법 2. 프로토콜(인터페이스) 사용하기

위의 방법 1에서 구현한 fly() 메서드를 Duck 클래스에서 빼고 Flyable이라는 Protocol을 만들어서 채택하는 구조로 만들어요.

이렇게 하면 같은 Duck이라고 하더라도 "하늘을 나는 능력을 가진 오리"만 이 프로토콜을 채택시켜서 문제를 해결할 수 있어요.

 

🧐 책에서 말하는 이 방법의 단점

(자바 기준으로) 이렇게 구현하면 코드 중복이 많이 발생해요.
fly의 기능이 대부분 오리에서 같다고 했을 때, Flyable을 채택하는 오리들에서 같은 코드가 불필요하게 반복되어야 해요.

날아가는 동작을 조금 바꾸기 위해 Duck의 서브클래스에서 fly 메서드들을 전부 수정해야 할 수도 있다는 단점이 있어요.

 

➡️ Swift에서는 사실 Protocol의 extension에서 func을 정의하는 기능이 있기 때문에 이 문제에서 벗어날 수 있어요.
Java와 다르게 POP의 관점에서 코드를 구현할 수 있기 때문에 책에서 말하는 단점은 Swift에 적용되지 않는다고 생각해요.

 

🎨 디자인 원칙: 애플리케이션에서 달라지는 부분을 찾아내고, 달라지는 부분과 분리한다

달라지는 부분을 찾아서 나머지 코드에 영향을 주지 않도록 '캡슐화'해요.

그러면 코드를 변경하는 과정에서 의도치 않게 발생하는 일을 줄이면서 시스템의 유연성을 향상시킬 수 있어요.

이 원칙을 적용하는데 많은 시간을 쏟아야 해요.

 

바뀌는 부분은 따로 뽑아서 캡슐화한다. 그러면 나중에 바뀌지 않는 부분에는 영향을 미치지 않고 그 부분만 고치거나 확장할 수 있다

이 개념은 다른 모든 디자인 패턴의 기반을 이루는 원칙이에요.

이것을 기반으로 위의 오리 문제를 다시 살펴볼게요.

 

Duck 클래스를 '변화하는 부분과 그대로 있는 부분'으로 분리하려면, 2개의 클래스 집합을 만들어야 해요.

하나는 하늘을 나는 것과 관련된 것, 다른 하나는 꽥꽥 거리는 것과 관련된 부분이에요.
각 클래스 집합에는 각각의 행동을 구현한 것을 전부 집어넣어요.
예를 들어, 꽥꽥거리는 행동을 구현하는 클래스, 삑삑거리는 행동을 구현하는 클래스, 그리고 아무 소리도 내지 않는 행동을 구현하는 클래스를 만들어요.

 

fly()와 quack()은 오리 종류에 따라 달라져요.

그래서 Duck 클래스로부터 이 두 메서드를 분리하려면 2개의 메서드 모두 Duck 클래스에서 끄집어내서 각 행동을 나타낼 클래스 집합을 새로 만들어야 해요.

 

그러면 이 행동들을 구현하는 클래스 집합은 어떻게 디자인해야 할까요?

최대한 유연하게 만드는 것이 좋아요!
애초에 이러한 문제가 발생했던 이유가 이 부분에서 변경점이 생길 가능성이 높아서였으니까요.

 

🎨 디자인 원칙: 구현보다는 인터페이스 맞춰서 프로그래밍한다.

각 행동은 인터페이스로 표현하고, 이런 인터페이스를 사용해서 행동을 구현해요.

이제 Duck 클래스에서 나는 행동과 꽥꽥거리는 행동을 구현하지 않아요.

행동(Behavior) 인터페이스는 Duck 클래스가 아니라 행동 클래스에서 구현해요.

 

"인터페이스에 맞춰서 프로그래밍한다"라는 말은 사실 "상위 형식에 맞춰서 프로그래밍한다"라는 말입니다.

여기서 말하는 인터페이스는 중의적으로 사용되었는데, 자바에서 말하는 인터페이스를 의미하기도 하고 인터페이스라는 개념을 지칭하기도 해요. 반드시 자바의 인터페이스(Swift의 프로토콜)를 사용하라는 뜻은 아니에요.

핵심은 실제 실행 시에 쓰이는 객체가 코드에 고정되지 않도록 상위 형식에 맞춰 프로그래밍해서 다형성을 활용해야 한다는 것이에요.

 

또한 여기서 "상위 형식에 맞춰서 프로그래밍하라"는 "변수를 선언할 때 보통 추상 클래스나 인터페이스 같은 상위 형식으로 선언해야 한다"라는 의미예요. 객체를 변수에 대입할 때 상위 형식을 구체적으로 구현한 형식이라면 어떤 객체든 넣을 수 있는 유연성이 생기기 때문이에요. "그러면 변수를 선언하는 클래스에서 실제 객체의 형식을 몰라도 된다"는 의미로도 해석될 수 있어요. 

 

이렇게 구현한 결과물은 아래와 같아요.

 

이렇게 디자인하면 다른 형식의 객체(오리가 아닌 다른 객체)에서도 나는 행동과 꽥꽥 거리는 행동을 재사용할 수 있어요.

이 행동 자체가 오리 안에 숨겨져있지 않으니까요!

 

그리고 Duck 클래스를 건드리지 않고도 새로운 행동을 추가할 수 있어요.

상속을 쓸 때 떠안게 되는 부담을 떨쳐 버리고 재사용의 장점을 가져갈 수 있어요 :]

 

🤔 Q. 행동만 나타내는 클래스는 어색해요. 클래스는 원래 어떤 대상을 나타내는 것 아닌가요? 상태, 행동을 모두 포함해야 하는 것 아닌가요?

객체지향 시스템에서는 질문한 내용이 맞습니다. 하지만 "행동"도 상태와 메서드를 가질 수 있어요! (최고 높이, 속도 등)

객체라는 개념이 반드시 어떤 하나의 물체로 한정될 필요는 없어요.

 

그럼 위의 프로토콜을 가지고 Duck을 다시 구현해 볼게요!

 

🐣 동적으로 오리의 행동 지정하기

앞서서 특정 구현에 맞춰서 프로그래밍하면 안 된다고 했어요.

현재는 앞에 있는 생성자를 보면 Quack라는 구상 클래스의 인스턴스로 선언되어 있기 때문에 Duck이 Quack의 구현에 맞춰져 있어요.

위에서는 프로퍼티의 생성 시점에 동작이 확정되지만, 이 부분을 유연하게 만들 수 있어요.

아래와 같이 메서드를 추가하면 코드 진행 중에 동작의 변경이 가능해요.

 

🤝 두 클래스의 관계

"A에는 B가 있다"의 관계를 생각해 보면, 오리에는 FlyBehavior, QuackBehavior가 있어요.

각각 나는 행동과 꽥꽥 거리는 행동을 위임해요.

이런 식으로 "두 클래스를 합치는 것을 구성(composition)을 이용한다"라고 해요.

 

🎨 디자인 원칙: 상속보다는 구성을 활용한다.

Composition을 활용하면 시스템의 유연성을 향상시킬 수 있어요.

 

 

🛠 iOS에서 전략 패턴 구현해보기

protocol Theme {
    var backgroundColor: UIColor { get }
    var textColor: UIColor { get }
    // 추가적인 테마 관련 프로퍼티 및 메서드 정의
}

struct LightTheme: Theme {
    var backgroundColor: UIColor = .white
    var textColor: UIColor = .black
    // 추가적인 테마 관련 프로퍼티 및 메서드 구현
}

struct DarkTheme: Theme {
    var backgroundColor: UIColor = .black
    var textColor: UIColor = .white
    // 추가적인 테마 관련 프로퍼티 및 메서드 구현
}

class ViewController: UIViewController {
    var theme: Theme
    
    init(theme: Theme) {
        self.theme = theme
        super.init(nibName: nil, bundle: nil)
    }
    
    // 뷰 컨트롤러의 테마 관련 로직을 구현
    // 예: 배경색 설정, 텍스트 색상 설정 등
}

위의 예시에서 Theme 프로토콜은 테마 관련 속성을 정의하고 있어요. 
그리고 LightTheme과 DarkTheme은 각각 테마 프로토콜을 구현한 전략 클래스에요. 

이렇게 구현된 전략 패턴을 통해 애플리케이션의 테마를 동적으로 변경할 수 있어요. 

 

 

📚 정리

전략 패턴(Strategy Pattern)은 알고리즘군을 정의하고 캡슐화해서 각각의 알고리즘군을 수정해서 쓸 수 있게 해 줘요.
전략 패턴을 사용하면 클라이언트로부터 알고리즘을 분리해서 독립적인 변경(관리)이 가능해요!