어댑터, 퍼사드 패턴

Adapter Pattern

특정 클래스 인터페이스를 클라이언트에서 요구하는 다른 인터페이스로 변환합니다. 인터페이스가 호환되지 않아 같이 쓸 수 없었던 클래스를 사용할 수 있게 도와줍니다.

Facade Pattern

서브시스템에 있는 일련의 인터페이스를 모아서 사용하기 쉽게 통합 인터페이스로 묶어줍니다.
facade: 겉모양, 외관

1. 오리와 칠면조 어댑터 구현하기

외주넣은 업체에서 제공한 클래스 라이브러리를 사용해야 합니다. 근데 그 인터페이스가 기존에 사용하던 인터페이스와 다른 상황이 생깁니다.
하지만, 기존에 사용하던 코드는 바꿀 수가 없는 상황이에요. 괜히 건드렸다가 무슨 사이드이펙트가 발생할 지 모르는 것이죠.
이럴 때, 외주 받은 클래스 라이브러리를 기존 인터페이스에 적응시켜주는 클래스를 만드는 것이 어댑터 패턴입니다.
아래 코드를 보면, MallardDuck은 Duck 프로토콜을 준수하는 클래스이고 WildTurkey는 Turkey를 준수하는 전혀 다른 인터페이스 입니다.
하지만, Duck을 준수하는 TurkeyAdapter 클래스에서 turkey 인스턴스를 구성(Composition)으로 가지고 있고, 그 인스턴스를 통해 메소드를 실행하고 있죠. 물론 그 반대도 가능합니다.

protocol Duck {
    func quack()
    func fly()
}

class MallardDuck: Duck {
    func quack() {
        print("꽥")
    }
    
    func fly() {
        print("날고 있어요!")
    }
}

//칠면조
protocol Turkey {
    func gobble() //꽥이 아니라 골골골~
    func fly() //칠면조는 날긴 날지만, 오리처럼은 잘 못납니다.
}

class WildTurkey: Turkey {
    func gobble() {
        print("골골")
    }
    
    func fly() {
        print("짧은 거리를 날고 있어요!")
    }
}

class DuckAdapter: Turkey {
    let duck: Duck
    
    init(_ duck: Duck) {
        self.duck = duck
    }
    
    func gobble() {
        duck.quack()
    }
    
    func fly() {
        duck.fly()
    }
}

class TurkeyAdapter: Duck {
    let turkey: Turkey
    
    init(_ turkey: Turkey) {
        self.turkey = turkey
    }
    
    func quack() {
        turkey.gobble()
    }
    
    func fly() {
        (0...5).forEach { _ in
            turkey.fly()
        }
    }
}

import Foundation

let duck = MallardDuck()
let turkey = WildTurkey()

let turkeyAdapter: Duck = TurkeyAdapter(turkey)
let duckAdapter: Turkey = DuckAdapter(duck)

print("\n--- 칠면조가 말하길 ---")
turkey.gobble()
turkey.fly()

print("\n--- 오리가 말하길 ---")
duck.quack()
duck.fly()

print("\n--- 칠면조 어댑터가 말하길 ---")
//TurkeyAdapter 클래스지만, Duck 프로토콜을 준수, 다형성
turkeyAdapter.quack()
turkey.fly()

print("\n--- 오리 어댑터가 말하길 ---")
duckAdapter.gobble()
duckAdapter.fly()

/*
 --- 칠면조가 말하길 ---
 골골
 짧은 거리를 날고 있어요!

 --- 오리가 말하길 ---
 꽥
 날고 있어요!

 --- 칠면조 어댑터가 말하길 ---
 골골
 짧은 거리를 날고 있어요!

 --- 오리 어댑터가 말하길 ---
 꽥
 날고 있어요!
 */

2. 어댑터 패턴

어댑터(TurkeyAdapter)에서 타깃 인터페이스(Duck)를 구현합니다.
어댑터(TurkeyAdapter)는 어댑티(Turkey) 인터페이스의 인스턴스를 구성(Composition)으로 가지고 있지요. 이런 접근법은 어댑티(Turkey) 인터페이스의 모든 서브 클래스에 어댑터(TurkeyAdapter)를 쓸 수 있다는 장점이 있습니다.
그 말은, 나중에 어댑티(Turkey) 인터페이스를 준수하는 서브 클래스를 추가해도 호환된다는 뜻입니다.
어댑터 패턴은 타깃 인터페이스가 크다면 그에 비례해서 복잡해집니다. 코드를 엄청나게 많이 고쳐야 된다는 소리죠. 그냥 모든 변경 사항을 캡슐화할 클래스 하나만 제공하는 방법도 고려해보면 좋습니다.
대부분은 어댑터는 하나의 클래스만 감싸지만, 그렇지 않은 경우도 있습니다.
코드에 오래된 인터페이스와 새로만든 인터페이스가 있어서 한쪽만 어댑터를 사용해야 되나 고민된다면, 두 인터페이스를 모두 지원하는 다중 어댑터(Two Way Adapter)를 만들면 됩니다.

3. 객체 어댑터와 클래스 어댑터

클래스 어댑터
- 다중 상속(Multiple Inheritance)을 사용합니다. 다중 상속을 지원하는 언어에서만 사용 가능합니다.
- 인터페이스를 준수하는 어댑터 클래스를 만드는 객체 어댑터와는 다르게 인터페이스가 아닌 MallardDuck과 WildTurkey 클래스 2개를 다중 상속해서 어댑터 클래스를 만듭니다.
- 그렇기 때문에, 특정 어댑티 클래스에만 적용할 수 있다는 단점이 있습니다. 하지만 서브클래스이기 때문에 어댑티의 행동을 오버라이드 할 수 있는 장점이 있습니다.
- 상속을 사용하므로 코드 분량은 상대적으로 적습니다.
객체 어댑터
- 구성(Composition)을 사용합니다.
- 구성으로 어댑티에 요청을 전달합니다.
- 구성을 사용하므로 어댑터 클래스와 그 서브클래스들에 대해서도 어댑터 역할이 가능합니다.
- 어댑터 코드에 어떤 행동을 추가하면 어댑티와 모든 서브클래스에 그대로 적용되기 때문에 상대적으로 유연성이 뛰어납니다.

4. Enumeration을 Iterator에 적응시키기

둘 다 자바의 인터페이스인데, Enumeration이 구형 Iterator가 신형이랍니다. iOS도 objc와 swift가 있으니 대충 그런가보다 하고 이해하면 되겠네요.
hasNext()는 hasMoreElements()로, next()는 nextElement()로 대응됩니다.
하지만 Iterator의 remove()는 Enumeration에 해당하는 기능을 제공하지 않습니다. 이처럼 메소드가 일대일로 대응되지 않는 상황에서는 어댑터 차원에서 완벽한 구현 방법은 없습니다. 그나마 가장 좋은 방법은 런타임 예외를 던지는 것입니다. 자바에서는 UnsupportedOperationException이라는 게 있다고 합니다.

protocol Iterator {
    associatedtype Item //타입은 나중에 결정할게!
    func hasNext() -> [Item]
    func next() -> Item
    func remove()
}
    
//원래는 얘에도 타입이 지정되어야 하는데, 구성으로 해버리면 Swift에서는 컴파일 에러가 발생.
protocol Enumeration {
    func hasMoreElements() -> [String]
    func nextElement() -> String
}
    
class EnumerationIterator {
    let enumeration: Enumeration
    
    init(enumeration: Enumeration) {
        self.enumeration = enumeration
    }

    typealias Item = String //String 타입으로 리턴하기로 결정 !

    func hasNext() -> [String] {
        return enumeration.hasMoreElements()
    }

    func next() -> String {
        return enumeration.nextElement()
    }

    func remove() {
        fatalError("지원하지 않는 메소드입니다.")
    }
}

5. 데코레이터, 어댑터, 퍼사드 패턴

데코레이터 패턴
- 여러개의 클래스를 감쌀 수 있습니다.
- 인터페이스는 바꾸지 않고 데코레이터로 감싸질 때 마다 기능/책임을 추가하는 용도로 사용된다.
어댑터 패턴
- 여러개의 클래스를 감쌀 수 있습니다.
- 인터페이스를 다른 인터페이스로 용도로 사용된다.
퍼사드 패턴
- 여러개의 클래스를 감쌀 수 있습니다.
- 복잡한 인터페이스를 단순하게 만드는 용도로 사용된다.

//데코레이터 패턴 
var darkroast: Beverage = DarkRoast()
darkroast = Mocha(beverage: darkroast)
darkroast = Whip(beverage: darkroast)
print("\(darkroast.getDescription()) $\(darkroast.cost())")
/*
 다크 로스트 원두, 모카, 휘핑크림 $5.99
 */
    

//어댑터 패턴
let duck = MallardDuck()
let turkey = WildTurkey()
let turkeyAdapter: Duck = TurkeyAdapter(turkey)

print("\n--- 칠면조가 말하길 ---")
turkey.gobble()
turkey.fly()
print("\n--- 오리가 말하길 ---")
duck.quack()
duck.fly()
print("\n--- 칠면조 어댑터가 말하길 ---")
turkeyAdapter.quack()
turkey.fly()

/*
 --- 칠면조가 말하길 ---
 골골
 짧은 거리를 날고 있어요!
    
 --- 오리가 말하길 ---
 꽥
 날고 있어요!

 --- 칠면조 어댑터가 말하길 ---
 골골
 짧은 거리를 날고 있어요!
 */

6. 퍼사드 패턴

복잡한 인터페이스를 단순하게 바꾸려고 인터페이스를 변경합니다.
하나 이상의 클래스 인터페이스를 깔끔하면서도 효과적인 퍼사드(겉모양, 외관)으로 덮어줍니다.
퍼사드 클래스는 서브 시스템 클래스(Light, Screen, Popper...)를 캡슐화 하지 않습니다. 그냥 더 쉽게 사용하기 위한 인터페이스만 제공할 뿐이죠. 이게 대표적인 장점인데, 캡슐화 하지 않기 때문에 원한다면 얼마든지 원래 서브 시스템 클래스 인스턴스를 생성한다던지 해서 계속 사용할 수 있게 합니다.
최소 지식 원칙(Principle of Least Knowledge, LoD, Law of Demeter)을 준수하는데 도움이 됩니다.

7. 홈시어터 퍼사드 구현하기

공통 코드

class Popper {
    func on() {
        print("팝콘 기계가 켜졌습니다.")
    }
    
    func off() {
        print("팝콘 기계가 꺼졌습니다.")
    }
    
    func pop() {
        print("팝콘 기계에서 팝콘을 튀기고 있습니다.")
    }
}

class Light {
    func dim(_ num: Int) {
        print("조명 밝기를 \(num)%로 설정합니다.")
    }
    
    func on() {
        print("조명이 켜졌습니다.")
    }
}

class Screen {
    func down() {
        print("스크린이 내려옵니다.")
    }
    
    func up() {
        print("스크린이 올라갑니다.")
    }
}

class Projector {
    func on() {
        print("프로젝터가 켜졌습니다.")
    }
    
    func off() {
        print("프로젝터가 꺼졌습니다.")
    }
    
    func wideScreenMode() {
        print("프로젝터 화면 비율을 와이드 모드로 설정합니다.")
    }
}

class Amp {
    func on() {
        print("앰프가 켜졌습니다.")
    }
    
    func off() {
        print("앰프가 꺼졌습니다.")
    }
    
    func setStreamingPlayer(_ player: String) {
        print("앰프를 스트리밍 플레이어와 연결합니다.")
    }
    
    func setSurroundSound() {
        print("앰프를 서라운드 모드로 설정합니다(5.1채널).")
    }
    
    func setVolume(_ volume: Int) {
        print("앰프 볼륨을 \(volume)으로 설정합니다.")
    }
}

class Player {
    func on() {
        print("스트리밍 플레이어가 켜졌습니다.")
    }
    
    func off() {
        print("스트리밍 플레이어가 꺼졌습니다.")
    }
    
    func stop(_ movieName: String) {
        print("스트리밍 플레이어에서 \(movieName)를 종료합니다.")
    }
    
    func play(_ movieName: String) {
        print("스트리밍 플레이어에서 \(movieName)를 재생합니다.")
    }
}

퍼사드 패턴 적용 전의 코드
- 영화를 보기 위해서는 할 일이 아주 많습니다.
- 팝콘 기계를 켜고, 튀기고, 조명을 조절하고, 스크린을 내리고, 프로젝트를 켜고...
- 영화를 끌 때도 마찬가지로 위의 과정을 역순으로 해야 합니다. 힘들어요.

let popper = Popper()
let lights = Light()
let screen = Screen()
let projector = Projector()
let amp = Amp()
let player = Player()

print("\n--- 영화 볼 준비 중 ---")
popper.on()
popper.pop()
lights.dim(10)
screen.down()
projector.on()
projector.wideScreenMode()
amp.on()
amp.setSurroundSound()
amp.setVolume(5)
player.on()
player.play("탑 건: 매버릭")

print("\n--- 홈시어터를 끄는 중 ---")
popper.off()
lights.on()
screen.up()
projector.off()
amp.off()
player.stop("탑 건: 매버릭")
player.off()
    
/*
 --- 영화 볼 준비 중 ---
 팝콘 기계가 켜졌습니다.
 팝콘 기계에서 팝콘을 튀기고 있습니다.
 조명 밝기를 10%로 설정합니다.
 스크린이 내려옵니다.
 프로젝터가 켜졌습니다.
 프로젝터 화면 비율을 와이드 모드로 설정합니다.
 앰프가 켜졌습니다.
 앰프를 서라운드 모드로 설정합니다(5.1채널).
 앰프 볼륨을 5으로 설정합니다.
 스트리밍 플레이어가 켜졌습니다.
 스트리밍 플레이어에서 탑 건: 매버릭를 재생합니다.

 --- 홈시어터를 끄는 중 ---
 팝콘 기계가 꺼졌습니다.
 조명이 켜졌습니다.
 스크린이 올라갑니다.
 프로젝터가 꺼졌습니다.
 앰프가 꺼졌습니다.
 스트리밍 플레이어에서 탑 건: 매버릭를 종료합니다.
 스트리밍 플레이어가 꺼졌습니다.
 */

퍼사드 패턴 적용 후의 코드
- 팝콘, 조명, 스크린, 프로젝트 같은 서브 시스템을 합쳐서 통합 인터페이스를 만들어버립니다.

class HomeTheaterFacade {
    let popper: Popper
    let lights: Light
    let screen: Screen
    let projector:Projector
    let amp: Amp
    let player: Player
    
    init(_ popper: Popper,
         _ lights: Light,
         _ screen: Screen,
         _ projector: Projector,
         _ amp: Amp,
         _ player: Player) {
        self.popper = popper
        self.lights = lights
        self.screen = screen
        self.projector = projector
        self.amp = amp
        self.player = player
    }
    
    func watchMovie(_ movieName: String) {
        print("\n--- 영화 볼 준비 중 ---")
        popper.on()
        popper.pop()
        lights.dim(10)
        screen.down()
        projector.on()
        projector.wideScreenMode()
        amp.on()
        amp.setSurroundSound()
        amp.setVolume(5)
        player.on()
        player.play(movieName)
    }
    
    func endMovie(_ movieName: String) {
        print("\n--- 홈시어터를 끄는 중 ---")
        popper.off()
        lights.on()
        screen.up()
        projector.off()
        amp.off()
        player.stop(movieName)
        player.off()
    }
}

let popper = Popper()
let lights = Light()
let screen = Screen()
let projector = Projector()
let amp = Amp()
let player = Player()

let homeTheater = HomeTheaterFacade(popper, lights, screen, projector, amp, player)
homeTheater.watchMovie("탑 건: 매버릭")
homeTheater.endMovie("탑 건: 매버릭")

/*
 --- 영화 볼 준비 중 ---
 팝콘 기계가 켜졌습니다.
 팝콘 기계에서 팝콘을 튀기고 있습니다.
 조명 밝기를 10%로 설정합니다.
 스크린이 내려옵니다.
 프로젝터가 켜졌습니다.
 프로젝터 화면 비율을 와이드 모드로 설정합니다.
 앰프가 켜졌습니다.
 앰프를 서라운드 모드로 설정합니다(5.1채널).
 앰프 볼륨을 5으로 설정합니다.
 스트리밍 플레이어가 켜졌습니다.
 스트리밍 플레이어에서 탑 건: 매버릭를 재생합니다.

 --- 홈시어터를 끄는 중 ---
 팝콘 기계가 꺼졌습니다.
 조명이 켜졌습니다.
 스크린이 올라갑니다.
 프로젝터가 꺼졌습니다.
 앰프가 꺼졌습니다.
 스트리밍 플레이어에서 탑 건: 매버릭를 종료합니다.
 스트리밍 플레이어가 꺼졌습니다.
 */

8. 최소 지식 원칙(PoLK, LoD)

최소 지식 원칙(Principle of Least Knowledge)은 디미터/데메테르 법칙(Law of Demeter)이나 축약해서 LoD 라고도 불린다.
한 마디로 정의하면 객체 사이의 상호작용은 될 수 있으면 아주 가까운 '친구'사이에만 허용하는 것이 좋다는 말이다.
즉, 시스템을 디자인 할 때, 어떤 객체든 그 객체와 상호작용을 하는 클래스의 개수와 상호작용 방식에 주의를 기울여야 한다는 뜻이다.
이 원칙을 잘 따르면 여러 클래스가 복잡하게 얽혀 있어서 시스템의 어느 한 부분을 변경했을 때, 다른 부분까지 줄줄이 고쳐야 하는 상황을 방지할 수 있습니다.
이 원칙을 잘 따르지 않는 코드는 여러 클래스가 서로 복잡하게 의존하고 있어 관리하기도 힘들고, 남들이 이해하기 어려운 코드가 됩니다.
장점이 있는만큼 단점도 있습니다. 원칙을 적용하다보면 '래퍼'클래스를 더 만들어야 할 수도 있습니다. 그러면 시스템이 복잡해지고, 개발 시간도 늘어나고, 성능도 떨어집니다.
친구를 만들지 않는 4개의 가이드라인
- 객체 자체는 호출 (O)
- 메소드에 매개변수로 전달된 객체는 호출 (O)
- 메소드를 생성하거나 인스턴스를 만든 객체는 호출 (O)
- 객체에 속하는 구성 요소는 호출 (O)