디자인 패턴

생성 패턴은 객체 생성 메커니즘을 다루며, 객체를 생성하는 방법과 시점을 유연하게 제어하는 데 초점을 맞춘다. 이 패턴들은 시스템이 특정 클래스에 의존하지 않고 객체를 생성할 수 있도록 하여, 객체 생성 과정을 캡슐화하고 추상화한다. 주로 객체 생성의 복잡성을 숨기거나, 생성 과정을 통제하여 시스템의 유연성과 재사용성을 높이는 목적으로 사용된다.

생성 패턴은 크게 클래스 생성 패턴과 객체 생성 패턴으로 나눌 수 있다. 클래스 생성 패턴은 상속을 이용하여 생성 과정을 하위 클래스에 위임하는 반면, 객체 생성 패턴은 객체 합성을 통해 책임을 다른 객체에 위임한다. 대표적인 생성 패턴의 예시는 다음과 같다.

이러한 패턴들은 특정 문제 상황에 맞게 적용된다. 예를 들어, 싱글톤 패턴은 설정 관리자나 로거처럼 단 하나의 인스턴스만 필요한 경우에, 빌더 패턴은 많은 매개변수를 가진 복잡한 객체를 생성할 때 유용하다. 생성 패턴을 적절히 활용하면 코드의 결합도를 낮추고, 새로운 유형의 객체를 추가하기 쉬운 확장성 있는 설계를 가능하게 한다.

구조 패턴은 클래스나 객체의 구성을 통해 더 큰 구조를 형성하는 방법에 관한 패턴이다. 이 패턴들은 상속을 활용하여 인터페이스나 구현을 복합하는 데 중점을 둔다. 주로 시스템의 구조를 유연하고 효율적으로 설계하여 클래스와 객체 간의 관계를 단순화하거나 새로운 기능을 추가하기 쉽게 만드는 것이 목표이다.

대표적인 구조 패턴으로는 어댑터 패턴, 데코레이터 패턴, 퍼사드 패턴, 컴포지트 패턴, 프록시 패턴, 브리지 패턴, 플라이웨이트 패턴 등이 있다. 각 패턴은 특정한 구조적 문제를 해결한다. 예를 들어, 어댑터 패턴은 호환되지 않는 인터페이스를 가진 클래스들이 함께 작동하도록 해주며, 데코레이터 패턴은 객체에 동적으로 새로운 책임을 추가한다.

이 패턴들은 주로 객체 간의 관계를 설계할 때 사용되며, 복잡한 시스템을 여러 계층으로 분리하거나 서브시스템을 더 쉽게 사용할 수 있게 만드는 데 유용하다. 구조 패턴을 적용하면 시스템의 부분들을 독립적으로 변경하거나 확장하기 쉬워져 전체적인 유지보수성이 향상된다.

행동 패턴은 객체나 클래스 간의 책임 할당, 알고리즘 분리, 그리고 상호작용 방식을 다루는 패턴이다. 이 패턴들은 객체의 행동을 유연하게 구성하거나 변경할 수 있도록 하며, 실행 중인 알고리즘이나 책임을 동적으로 교체하는 데 중점을 둔다. 주로 객체 간의 통신 흐름을 효율적으로 관리하고 복잡한 제어 로직을 단순화하는 데 목적이 있다.

행동 패턴의 주요 특징은 알고리즘을 캡슐화하거나 객체 간의 결합도를 낮추는 것이다. 예를 들어, 스트래티지 패턴은 유사한 알고리즘 군을 정의하고 각각을 캡슐화하여 상호 교환 가능하게 만든다. 이렇게 하면 알고리즘을 사용하는 클라이언트 코드는 변경 없이 다양한 전략을 사용할 수 있다. 반면, 옵저버 패턴은 한 객체의 상태 변화를 여러 관찰 객체에 자동으로 알리는 일대다 의존성을 정의하여 객체 간의 느슨한 결합을 유지한다.

다른 주요 행동 패턴으로는 다음과 같은 것들이 있다.

이러한 패턴들은 특정 행동 관련 문제를 해결하는 검증된 템플릿을 제공한다. 올바르게 적용하면 코드의 재사용성과 유지보수성을 크게 향상시킬 수 있다. 그러나 패턴의 본질적인 의도와 적용 컨텍스트를 정확히 이해하지 않고 사용하면 오히려 설계를 불필요하게 복잡하게 만들 수 있다는 점에 유의해야 한다.

싱글톤 패턴은 생성 패턴에 속하며, 특정 클래스의 인스턴스가 오직 하나만 생성되도록 보장하고, 이 인스턴스에 대한 전역적인 접근점을 제공하는 패턴이다. 주로 데이터베이스 연결 풀, 로깅 객체, 설정 관리자, 캐시 등 애플리케이션 전반에서 단일 인스턴스만 존재해야 하는 공유 자원을 관리할 때 사용된다.

이 패턴의 핵심은 생성자를 외부에서 호출할 수 없도록 private으로 선언하고, 클래스 자신이 유일한 인스턴스를 생성하여 저장하는 정적 멤버 변수를 두는 것이다. 외부에서는 이 정적 멤버를 반환하는 정적 메서드(예: getInstance())를 통해서만 인스턴스에 접근할 수 있다. 이는 게으른 초기화 방식으로 처음 요청이 있을 때 인스턴스를 생성하거나, 클래스 로딩 시점에 미리 생성하는 방식으로 구현된다.

싱글톤 패턴의 주요 구현 방식과 고려사항은 다음과 같다.

이 패턴은 전역 상태를 만들 수 있어 단위 테스트를 어렵게 할 수 있다는 단점이 있다. 또한, 의존성 주입 원칙을 위반할 가능성이 있어 과도한 사용은 지양해야 한다.

팩토리 메서드 패턴은 객체 생성을 처리하는 생성 패턴 중 하나이다. 이 패턴은 상위 클래스에서 객체를 생성하는 인터페이스를 정의하되, 하위 클래스가 생성할 객체의 구체적인 타입을 결정하도록 한다. 이를 통해 객체 생성 코드를 하위 클래스로 분리하여, 상위 클래스의 코드가 특정 구현 클래스에 의존하지 않게 만든다.

패턴의 핵심 구조는 Creator와 Product라는 두 가지 추상 요소로 구성된다. Creator는 팩토리 메서드를 선언하는 추상 클래스 또는 인터페이스이며, 이 메서드는 Product 타입의 객체를 반환한다. ConcreteCreator 클래스들은 이 팩토리 메서드를 오버라이드하여 특정 ConcreteProduct 인스턴스를 생성하고 반환한다. 결과적으로 클라이언트 코드는 Creator 추상 타입을 통해 객체를 생성하게 되며, 실제로 어떤 구체적인 제품이 만들어지는지는 런타임에 결정된다.

이 패턴의 주요 이점은 결합도를 낮추는 데 있다. 시스템에 새로운 제품 타입을 추가해야 할 때, 기존의 클라이언트 코드를 수정하지 않고 새로운 ConcreteCreator 클래스를 도입하기만 하면 된다. 이는 개방-폐쇄 원칙을 잘 반영한 사례이다. 또한, 생성 로직이 한 곳에 집중되어 코드의 유지보수성이 향상된다.

팩토리 메서드 패턴은 의존성 주입 프레임워크나 다양한 GUI 라이브러리에서 위젯을 생성할 때, 그리고 객체 풀을 관리할 때 흔히 활용된다. 단순한 객체 생성이 아니라 생성 과정에 복잡한 로직이 포함되거나, 생성될 객체의 타입이 실행 시점에 동적으로 결정되어야 하는 상황에서 특히 유용하다.

옵저버 패턴은 객체 사이의 일대다 의존 관계를 정의하여, 한 객체(주제 또는 발행자)의 상태가 변경될 때 그 객체에 의존하는 모든 객체(옵저버 또는 구독자)에게 자동으로 알림이 가고 갱신될 수 있도록 하는 행동 패턴이다. 이 패턴은 주로 분산된 시스템 간의 이벤트 처리를 효과적으로 관리하기 위해 사용된다.

패턴의 핵심 구조는 주제 인터페이스와 옵저버 인터페이스로 구성된다. 주제는 옵저버들을 등록, 제거, 알림하는 메서드를 제공한다. 옵저버는 상태 갱신을 위한 메서드(예: update())를 정의한다. 구체적인 주제 객체는 상태를 저장하고, 상태가 변경되면 등록된 모든 옵저버 객체의 갱신 메서드를 호출한다. 구체적인 옵저버 객체는 주제에 자신을 등록하고, 주제로부터의 알림을 받아 자신의 상태를 적절히 동기화한다.

이 패턴의 주요 적용 사례로는 GUI 프로그래밍에서의 이벤트 처리 시스템, 모델-뷰-컨트롤러 아키텍처에서 모델과 뷰의 분리, 그리고 발행-구독 메시징 시스템 등이 있다. 예를 들어, 사용자 인터페이스에서 데이터 모델이 변경되면 이를 표시하는 여러 뷰들이 자동으로 새로고침되는 구조를 구현할 때 유용하다.

옵저버 패턴의 장점은 주제와 옵저버 간의 느슨한 결합을 유지한다는 점이다. 주제는 옵저버들의 구체적인 클래스를 알 필요 없이 인터페이스만을 통해 통신한다. 이는 새로운 유형의 옵저버를 쉽게 추가할 수 있게 하여 시스템의 확장성을 높인다. 그러나 많은 수의 옵저버가 등록되어 있을 경우 알림 순서가 중요해지거나, 성능에 영향을 미칠 수 있으며, 옵저버가 제대로 해제되지 않으면 메모리 누수가 발생할 수 있는 주의점도 존재한다.

어댑터 패턴은 서로 다른 인터페이스를 가진 클래스들이 함께 동작할 수 있도록 중간에서 변환 역할을 하는 구조 패턴이다. 이 패턴은 호환되지 않는 인터페이스를 가진 기존 클래스를 다른 클래스에서 사용해야 할 때, 기존 클래스를 수정하지 않고도 연결할 수 있게 해준다. 전기 콘센트의 변환 플러그와 유사한 역할을 수행한다고 볼 수 있다.

어댑터 패턴은 주로 두 가지 방식으로 구현된다. 첫 번째는 클래스에 의한 어댑터 패턴으로, 어댑터 클래스가 타깃 인터페이스를 상속받고, 동시에 어댑티 클래스를 포함하는 방식이다. 두 번째는 객체에 의한 어댑터 패턴으로, 어댑터 클래스가 타깃 인터페이스를 구현하고 내부에 어댑티 객체를 합성하여 사용하는 방식이다. 후자가 더 유연한 구조를 가지는 경우가 많다.

이 패턴의 주요 구성 요소는 다음과 같다.

어댑터 패턴은 레거시 시스템을 새로운 시스템과 통합해야 하거나, 서로 다른 벤더가 제공한 라이브러리를 함께 사용해야 할 때 매우 유용하다. 기존 코드를 재사용할 수 있게 하면서도, 클라이언트 코드는 일관된 인터페이스를 통해 작업을 수행할 수 있다. 그러나 너무 많은 어댑터가 생성되면 시스템의 전체 구조가 복잡해질 수 있다는 점에 유의해야 한다.

스트래티지 패턴은 행동 패턴에 속하는 디자인 패턴으로, 특정 작업을 수행하는 여러 알고리즘을 정의하고 각 알고리즘을 별도의 클래스로 캡슐화하여 상호 교환 가능하게 만드는 패턴이다. 이 패턴의 핵심은 알고리즘을 사용하는 클라이언트 코드와 알고리즘의 구현을 분리하는 것이다. 클라이언트는 구체적인 알고리즘 구현이 아닌, 공통의 인터페이스에만 의존하게 된다.

주요 구성 요소는 다음과 같다. 첫째, 알고리즘의 공통 인터페이스를 정의하는 전략 인터페이스가 있다. 둘째, 이 인터페이스를 구현하는 구체적인 알고리즘 클래스들이다. 셋째, 전략 인터페이스를 참조하여 알고리즘을 사용하는 컨텍스트 클래스이다. 컨텍스트는 전략 객체를 구성(주입)받아 이를 통해 작업을 위임한다. 이로 인해 알고리즘을 런타임에 동적으로 변경할 수 있다.

이 패턴의 가장 큰 장점은 개방-폐쇄 원칙을 잘 준수한다는 점이다. 새로운 알고리즘을 추가하려면 새로운 전략 클래스를 만들기만 하면 되며, 기존의 컨텍스트 코드를 수정할 필요가 없다. 또한 조건문(if-else 또는 switch 문)을 제거하여 코드를 간결하게 하고, 각 알고리즘을 독립적으로 테스트하기 용이하다.

일반적인 적용 예시는 다음과 같다.

단, 적용할 알고리즘이 단 하나뿐이거나 거의 변하지 않는 경우에는 불필요한 복잡성을 초래할 수 있다. 또한 클라이언트가 적절한 전략 객체를 생성하고 컨텍스트에 주입해야 하는 책임이 생긴다.

적절한 디자인 패턴을 선택하는 것은 패턴의 이점을 최대화하고 부작용을 최소화하는 핵심 단계이다. 올바른 선택은 먼저 해결해야 할 구체적인 문제 상황을 명확히 정의하는 데서 시작한다. 예를 들어, 객체 생성 과정이 복잡하거나 유연성이 필요한 경우 생성 패턴을, 기존 클래스들의 인터페이스를 호환시켜야 하는 경우 구조 패턴을, 알고리즘이나 객체 간 책임 분배, 통신 방식을 정의해야 하는 경우 행동 패턴을 후보로 고려한다.

패턴 선택 시에는 해당 패턴이 해결하려는 의도와 적용 결과를 충분히 이해해야 한다. 각 패턴은 특정 문제 상황에 대한 검증된 해결책을 제시하지만, 그 해결책이 항상 현재 직면한 문제의 맥락에 완벽히 부합하는 것은 아니다. 따라서 패턴의 구조뿐만 아니라 패턴 간의 협력 관계와 트레이드오프도 고려해야 한다. 예를 들어, 팩토리 메서드 패턴은 템플릿 메서드 패턴과 함께 사용되기도 하며, 옵저버 패턴은 복잡한 의존성을 관리하는 대신 성능 저하나 메모리 누수의 위험을 초래할 수 있다.

최종 결정은 시스템의 전체적인 설계 목표와 제약 조건에 기반해야 한다. 아래 표는 몇 가지 일반적인 문제 상황과 고려할 수 있는 대표적인 패턴 후보를 보여준다.

결국, 패턴은 목적이 아니라 수단이다. 문제의 본질을 정확히 파악한 후, 패턴 카탈로그를 '해결책 사전'이 아니라 '설계 아이디어의 보고'로 참조하여 가장 적합한 설계를 도출하는 것이 중요하다.

디자인 패턴은 반복적으로 발생하는 설계 문제에 대한 검증된 해결책을 제공하지만, 모든 상황에 무조건 적용해야 하는 만능 도구는 아니다. 패턴의 과도한 적용은 오히려 설계를 불필요하게 복잡하게 만들고, 코드의 가독성과 유지보수성을 떨어뜨릴 수 있다. 간단한 문제를 해결하는 데 여러 개의 패턴을 중첩해서 사용하면, 설계 의도를 파악하기 어려워지고 런타임 성능에도 부정적인 영향을 미칠 수 있다.

패턴 적용의 가장 큰 위험성은 문제의 본질을 이해하지 않고 패턴 자체를 목적으로 삼는 경우다. 이는 '솔루션을 찾을 문제를 만들기'에 해당한다. 예를 들어, 단순한 조건문으로 처리할 수 있는 변형을 위해 스트래티지 패턴을 도입하거나, 인스턴스 생성이 한 번만 일어나는 것이 분명한 상황에서 싱글톤 패턴을 적용하는 것은 설계 과잉의 전형적인 예시다. 패턴은 문제에서 출발해야 하며, 해결책이 아닌 문제가 먼저 존재해야 한다.

과도한 패턴 적용은 다음과 같은 구체적인 문제를 초래한다.

따라서 패턴을 적용할 때는 YAGNI(You Ain't Gonna Need It) 원칙과 KISS(Keep It Simple, Stupid) 원칙을 상기하는 것이 중요하다. 현재 명확히 요구되는 기능과 예상되는 변경만을 고려하여 최소한의 설계를 선택해야 한다. 디자인 패턴은 설계를 개선하는 수단이지, 그 자체가 목표가 되어서는 안 된다.

객체지향 프로그래밍은 디자인 패턴의 등장과 발전에 가장 직접적인 영향을 미친 프로그래밍 패러다임이다. 디자인 패턴의 대부분은 객체지향의 핵심 원리인 캡슐화, 상속, 다형성을 효과적으로 활용하여 설계 문제를 해결하는 방법을 제시한다. 예를 들어, 스트래티지 패턴은 알고리즘 군을 정의하고 각각을 캡슐화하여 상호 교환 가능하도록 만드는데, 이는 다형성을 이용한 전형적인 해결책이다.

디자인 패턴은 객체지향 설계에서 반복적으로 발생하는 문제에 대한 검증된 해결 방안을 문서화한 것이다. 객체지향 프로그래밍의 목표 중 하나는 변경에 유연하고 재사용성이 높은 소프트웨어를 만드는 것이며, 디자인 패턴은 이러한 목표를 달성하는 구체적인 설계 기법을 제공한다. 팩토리 메서드 패턴은 객체 생성 로직을 캡슐화하고, 어댑터 패턴은 호환되지 않는 인터페이스를 함께 작동하게 함으로써 시스템의 결합도를 낮춘다.

다음 표는 주요 객체지향 원리와 이를 활용하는 대표적인 디자인 패턴의 관계를 보여준다.

따라서 디자인 패턴을 효과적으로 이해하고 적용하기 위해서는 객체지향 프로그래밍의 기본 원리에 대한 깊은 이해가 선행되어야 한다. 패턴은 객체지향 설계의 어려움을 해소하고, 보다 우아하고 견고한 코드 구조를 만드는 데 기여한다.

함수형 프로그래밍은 상태 변경과 가변 데이터를 피하고, 순수 함수의 조합과 고차 함수의 적용을 중심으로 프로그램을 구성하는 패러다임이다. 이 패러다임은 디자인 패턴과의 관계에서 두 가지 주요 관점을 보인다. 첫째, 전통적인 객체지향 디자인 패턴 중 상당수는 함수형 프로그래밍의 기본 개념으로 더 간결하게 표현되거나 대체될 수 있다. 예를 들어, 스트래티지 패턴은 고차 함수에 함수를 인자로 전달하는 방식으로, 옵저버 패턴은 스트림과 같은 데이터 흐름 추상화로 구현될 수 있다. 둘째, 함수형 프로그래밍은 모나드, 펑터, 리프팅과 같은 새로운 수준의 추상화와 패턴을 발전시켰다.

이러한 패턴들은 부수 효과를 제어하고 합성을 강조하는 함수형 프로그래밍의 핵심 문제를 해결한다. 결과적으로, 함수형 프로그래밍 환경에서는 일부 고전적인 디자인 패턴의 필요성이 줄어들거나 형태가 변형되는 경향이 있다. 반면, 두 패러다임을 혼합하는 현대적인 언어(예: 스칼라, 코틀린, 스위프트)에서는 객체지향 구조와 함수형 패턴이 공존하며, 상황에 맞는 최적의 설계를 위해 함께 활용된다.