퍼사드 패던이란?

디자인 패턴 중 구조 패턴에 한 종류로써 라이브러리에 대한, 프레임워크에 대한 또는 다른 클래스들의 복잡한 집합에 대한 단순화된 인터페이스를 제공하는 구조적 디자인 패턴입니다.

퍼사드 패턴을 사용하는 이유

시스템의 구조를 단순화하고, 코드의 가독성을 높이며 유지 보수를 용이하게 하기 위해서 사용합니다.

1. 복잡성 관리
   • 시스템이 커지고 복잡해짐에 따라, 여러 가지 클래스와 객체들이 상호작용하는 방식이 복잡해질 수 있습니다. 퍼사드 패턴은 이런 복잡성을 줄이고, 클라이언트가 필요한 기능을 간단한 인터페이스를 통해 사용할 수 있도록 합니다.
2. 단순한 인터페이스 제공
   • 퍼사드 패턴은 클라이언트가 여러 클래스와의 직접적인 상호작용을 피할 수 있게 하여, 단순하고 일관된 인터페이스를 제공합니다. 이를 통해 시스템을 더 쉽게 이해하고 사용할 수 있습니다.
3. 캡슐화
   • 퍼사드 패턴은 내부 구현을 숨기고, 외부에 단순한 인터페이스만 노출함으로써, 내부 시스템의 변경이 클라이언트 코드에 미치는 영향을 최소화할 수 있습니다. 이를 통해 모듈화와 재사용성을 높일 수 있습니다.
4. 의존성 감소
   • 클라이언트가 시스템의 세부 구현에 직접 의존하지 않도록하여, 시스템의 유연성과 확장성을 높일 수 있습니다. 퍼사드 패턴을 사용하면 클라이언트는 퍼사드 인터페이스만 의존하게 되어, 내부 시스템의 변경이 클라이언트에 미치는 영향을 줄일 수 있습니다.

퍼사드 패턴의 구조

1. 퍼사드 패턴을 사용하면 하위 시스템 기능들의 특정 부분에 편리하게 접근할 수 있습니다. 또 퍼사드는 클라이언트의 요청을 어디로 보내야 하는지와 움직이는 모든 부품을 어떻게 작동해야 하는지를 알고 있습니다.

2. 추가적인 퍼사드 클래스를 생성하여 하나의 퍼사드를 관련 없는 기능들로 오염시켜 복잡한 구조로 만드는 것을 방지할 수 있습니다. 추가 퍼사드들은 클라이언트들과 다른 퍼사드를 모두에 사용할 수 있습니다.

3. 복잡한 하위 시스템은 수십 개의 다양한 객체들로 구성됩니다. 이 모든 객체가 의미 있는 작업을 수행하도록 하려면, 하위 시스템의 세부적인 구현 정보를 깊이 있게 살펴야 합니다. 예를 들어 올바른 순서로 객체들을 초기화하고 그들에게 적절한 형식의 데이터를 제공하는 등의 작업을 수행해야 합니다. 하위 시스템 클래스들은 퍼사드의 존재를 인식하지 못합니다. 인들은 시스템 내에서 작동하며, 매개체 없이 직접 서로와 작업합니다.

4. 클라이언트는 하위 시스템 객체들을 직접 호출하는 대신 퍼사드를 사용합니다.

퍼사드 예시 코드

// 이것들은 복잡한 타사 비디오 변환 프레임워크 클래스의 일부입니다. 해당 프레임워크
// 코드는 우리가 제어할 수 없기 때문에 단순화할 수 없습니다.

class VideoFile
// …

class OggCompressionCodec
// …

class MPEG4CompressionCodec
// …

class CodecFactory
// …

class BitrateReader
// …

class AudioMixer
// …

// 퍼사드 클래스를 만들어 프레임워크의 복잡성을 간단한 인터페이스 뒤에 숨길 수
// 있습니다. 기능성과 단순함을 상호보완하는 것이죠.
class VideoConverter is
    method convert(filename, format):File is
        file = new VideoFile(filename)
        sourceCodec = (new CodecFactory).extract(file)
        if (format == "mp4")
            destinationCodec = new MPEG4CompressionCodec()
        else
            destinationCodec = new OggCompressionCodec()
        buffer = BitrateReader.read(filename, sourceCodec)
        result = BitrateReader.convert(buffer, destinationCodec)
        result = (new AudioMixer()).fix(result)
        return new File(result)

// 애플리케이션 클래스들은 복잡한 프레임워크에서 제공하는 수많은 클래스에 의존하지
// 않습니다. 또한 프레임워크의 전환을 결정한 경우에는 퍼사드 클래스만 다시 작성하면
// 됩니다.
class Application is
    method main() is
        convertor = new VideoConverter()
        mp4 = convertor.convert("funny-cats-video.ogg", "mp4")
        mp4.save()

장단점

• 장점
  • 복잡한 하위 시스템에서 코드를 별도로 분리할 수 있습니다.
• 단점
  • 퍼사드는 앱의 모든 클래스에 결합된 전지전능한 객체가 될 수 있습니다.

다른 패턴과의 관계

• 퍼사드 는 기존 객체들을 위한 새 인터페이스를 정의하는 반면 어댑터는 기존의 인터페이스를 사용할 수 있게 만들려고 노력합니다. 또 어댑터는 일반적으로 하나의 객체만 래핑하는 반면 퍼사드는 많은 객체의 하위시스템과 함계 작동합니다.
• 추상 팩토리 는 하위 시스템 객체들이 클라이언트 코드에서 생성되는 방식만 숨기고 싶을 때 퍼사드 대신 사용할 수 있습니다.
• 플라이웨이트는 작은 객체들을 많이 만드는 방법을 보여 주는 반면 퍼사드 패턴은 전체 하위 시스템을 나타내는 단일 객체를 만드는 방법을 보여 줍니다.
• 중재자와 퍼사드 패턴은 비슷한 역할을 합니다. 둘 다 밀접하게 결합된 많은 클래스 간의 협업을 구성하려고 합니다.
  - 퍼사드 패턴은 객체들의 하위 시스템에 대한 단순화된 인터페이스를 정의하지만 새로운 기능을 도입하지 않습니다. 하위 시스템 자체는 퍼사드를 인식하지 못하며, 하위 시스템 내의 객체들은 서로 통신할 수 있습니다.
  - 중재자는 시스템 컴포넌트 간의 통신을 중앙 집중화합니다. 컴포넌트들은 중재자 객체에 대해서만 알며 서로 직접 통신하지 않습니다.
• 대부분의 경우 하나의 퍼사드 객체만 있어도 충분하므로 퍼사드 패턴의 클래스는 종종 싱그톤으로 변환될 수 있습니다.
• 퍼사드 패턴은 복잡한 객체 또는 시스템을 보호하고 자체적으로 초기화한다는 점에서 프록시와 유사합니다. 퍼사드 패턴과 달리 프록시는 자신의 서비스 객체와 같은 인터페이스를 가지므로 이들은 서로 상호 교환이 가능합니다.

[참조]

• 디자인 패턴에 뛰어들기 - 알렉산더 슈베츠