디자인 패턴: 정의, 분류 및 주요 패턴 이해

1. 디자인 패턴이란?

디자인 패턴(design pattern)은 소프트웨어 설계에서

자주 발생하는 문제에 대해 재사용할 수 있는 우수한 해결책을 정형화한 것이다

다시 말해, 문제 상황(Context)과 그에 따른 여러 제약 조건(Problem),

그리고 이를 해결하는 일반적인 설계 해법(Solution)으로 구성된다.

디자인 패턴은 특정 구현 방법이나 프로그래밍 언어에 의존하지 않으며

다양한 상황에 적용될 수 있는 일종의 설계 템플릿이다.

"바퀴를 다시 발명하지 말라"는 격언처럼, 이미 검증된 설계 방식을 활용함으로써

개발자는 매번 처음부터 문제를 해결할 필요 없이 효율적인 해법을 적용할 수 있다.

이러한 "디자인 패턴" 개념은 원래 건축 분야에서 건축가 크리스토퍼 알렉산더가 제안한 아이디어에서 출발했다

소프트웨어 개발 영역에서도 이 개념을 도입하여, 기존에 잘 설계된 코드의 틀을 재활용함으로써

효율적이고 품질 좋은 코드를 작성할 수 있도록 도와주는 방법론으로 발전시켰다.

디자인 패턴은 구체적인 코드 조각이라기보다는 문제를 해결하기 위한 클래스 구조와

객체 상호작용에 관한 청사진(blueprint)이라고 할 수 있다.

---

2. 디자인 패턴이 필요한 이유

디자인 패턴을 활용하면 코드의 품질과 개발 생산성을 크게 향상시킬 수 있다.

이미 많은 사례를 통해 검증된 설계 방식을 따름으로써 얻을 수 있는 대표적인 이점들은 다음과 같다.

 

1. 재사용성:
검증된 구조를 여러 프로젝트나 모듈에서 반복 활용할 수 있어 중복 코드를 줄이고 개발 시간을 단축한다.

2. 유지보수성:
코드 구조가 명확하고 일관되게 설계되어 변경과 확장이 용이하다.
이는 코드 수정 시 오류 발생을 줄이고, 새로운 기능 추가를 수월하게 한다.

3.유연성:
객체지향의 원칙(예: 느슨한 결합과 캡슐화)을 잘 적용한 패턴들은 요구사항 변경에 유연하게 대응할 수 있다. 
높은 응집도와 낮은 결합도를 지닌 구조를 만들어 기능 변경 시 영향 범위를 최소화한다.

4. 확장성:
설계 단계에서 미래의 확장 가능성을 고려한 구조를 제공하여,
시스템이 커져도 구조를 해치지 않고 기능을 추가할 수 있다.
결과적으로 더 많은 사용자나 데이터 처리량을 무리 없이 감당할 수 있다.

 

또한 디자인 패턴은 개발자들 사이에 공통된 설계 용어를 제공한다.

예를 들어 "Observer 패턴을 적용했다"라고 하면 코드 구조와 의도를 쉽게 전달할 수 있어,

팀원 간 의사소통이 원활해진다. 이처럼 패턴은 개발 경험의 축적된 지식으로서,

초보 개발자에게도 검증된 설계 기법을 적용할 수 있는 길잡이 역할을 한다.

---

3. 디자인 패턴의 분류

디자인 패턴은 그 목적과 특성에 따라 여러 가지로 분류될 수 있다.

특히 1994년 에리히 감마(Erich Gamma) 등을 포함한 이른바

GoF(Gang of Four)에 의해 정리된 23개의 디자인 패턴들은

크게 생성(Creational) 패턴, 구조(Structural) 패턴, 행위(Behavioral) 패턴의 세 가지 범주로 나뉜다. 

각 분류의 개념은 다음과 같다:

 

생성 패턴(Creational Pattern):

객체 생성 방식과 관련된 패턴으로,

객체 생성 과정을 캡슐화하여 특정 객체 생성 변화가 프로그램 구조에 미치는 영향을 최소화하고 유연성을 제공한다.

 

구조 패턴(Structural Pattern):

클래스나 객체를 조합해 더 큰 구조를 만드는 패턴이다.

서로 다른 인터페이스를 지닌 두 객체를 묶어 단일 인터페이스를 제공하거나

객체들을 서로 묶어 새로운 기능을 제공하는 방식 등이 이에 포함된다.

 

행위 패턴(Behavioral Pattern):

객체나 클래스 사이의 효율적인 상호작용이나 역할 분담과 관련된 패턴이다.

한 객체가 혼자 수행하기 어려운 작업을 여러 객체에 나누어 처리하면서,

객체들 간의 결합도를 최소화하는 데 중점을 둔다.

이 세 가지 분류 체계는 디자인 패턴을 이해하고 조직화하는 데 널리 활용되며,

우리가 곧 살펴볼 개별 패턴들도 이 세 범주 중 하나에 속한다.

---

4. 주요 디자인 패턴 살펴보기

1. 생성 패턴 (Creational Patterns)

생성 패턴은 객체의 생성과 관련된 문제를 다루는 패턴들로,

객체 생성 로직을 캡슐화하여 유연한 객체 생성 구조를 제공한다.

대표적인 생성 패턴에는 싱글턴, 팩토리 메서드, 추상 팩토리, 빌더, 프로토타입 등이 있다.

아래에서 각 패턴의 구조와 활용 방법을 알아본다.

1) 싱글턴(Singleton) 패턴

싱글턴 패턴은 특정 클래스의 인스턴스를 오직 하나만 생성하고,

어디서든지 그 유일한 객체에 접근 가능하도록 하는 패턴이다.

주로 전역적으로 공유되는 리소스(예: 설정 정보, 로그 처리 객체 등)에 사용되며,

하나의 객체만 필요할 때 유용하다.

구조적으로는 생성자를 private으로 감추고,

클래스 내부에 자기 자신의 정적 인스턴스를 저장하여 제공하는 식으로 구현한다.

이렇게 하면 다른 곳에서 new로 인스턴스를 추가 생성하지 못하고,

정해진 곳을 통해서만 객체를 얻도록 강제한다.

예를 들어, 애플리케이션 내에 하나만 존재해야 하는 설정 매니저를 싱글턴으로 구현하여

어디서든 동일한 설정 객체를 참조하도록 할 수 있다.

2) 팩토리 메서드(Factory Method) 패턴

팩토리 메서드 패턴은 객체 생성 처리를 서브클래스로 분리하는 디자인 패턴이다.

즉, 상위 클래스(또는 인터페이스)에서 객체를 생성하는 추상 메서드(Factory 메서드)를 정의하고,

실제 객체 생성 과정은 이를 구현한 하위 클래스에서 결정하도록 한다.

이렇게 하면 객체 생성 코드와 사용 코드를 분리하여,

생성 방식의 변경이 있을 때도 상위 계층의 코드 수정을 최소화할 수 있다.

예를 들어, 게임에서 Enemy라는 추상 클래스가 있고 이를 상속받은 Goblin, Dragon 등이 있을 때,

팩토리 메서드를 통해 게임 레벨에 따라 다양한 Enemy 객체를 생성하도록 구현할 수 있다.

클라이언트는 팩토리 메서드를 호출하기만 하면 구체적인 클래스에 상관없이 적 객체를 얻을 수 있다.

3) 추상 팩토리(Abstract Factory) 패턴

추상 팩토리 패턴은 관련성 있는 여러 객체들을 일관된 방식으로 생성하기 위한 인터페이스를 제공하는 패턴이다.

서로 연관된 객체들의 제품군(Family)을 한꺼번에 만들어주는 공장을 추상화한 것으로,

구체적인 클래스에 직접 의존하지 않고도 호환성 있는 객체들을 생산할 수 있다.

구조적으로는 여러 개의 추상 팩토리 인터페이스와 구체 팩토리 클래스들이 있으며,

각각의 구체 팩토리는 특정 제품군을 생산하는 역할을 한다.

클라이언트는 추상 팩토리 인터페이스만 알고, 구체 팩토리를 선택함으로써 관련된 객체들을 손쉽게 생성할 수 있다.

예를 들어, GUI 라이브러리에서 서로 어울리는 스타일의 버튼, 텍스트필드, 체크박스를 생성할 때

추상 팩토리를 활용하면, "윈도우 스타일 위젯 팩토리", "리눅스 스타일 위젯 팩토리" 등을 통해

한 번의 호출로 일관된 GUI 컴포넌트 세트를 얻을 수 있다.

Abstract Factory 패턴의 UML 클래스 다이어그램.

서로 관련된 제품군(ProductA와 ProductB)에 대해 추상 팩토리(AbstractFactory)가 인터페이스를 정하고,

각 구체 팩토리(ConcreteFactory)가 연관된 제품 객체들을 생성한다.

4) 빌더(Builder) 패턴

빌더 패턴은 복잡한 객체의 생성 과정과 표현 방법을 분리하여,

동일한 생성 절차에서 서로 다른 표현의 객체를 생성할 수 있게 해주는 패턴이다.

즉, 객체를 구성하는 각 단계(부품 조립 단계)를 분리하여 유연하게 객체를 구성할 수 있도록 한다.

구조는 제품 객체를 만드는 Builder 추상 클래스(또는 인터페이스)와 이를 구현한 Concrete Builder들,

그리고 건축 감독격인 Director가 존재한다.

Director는 Builder 인터페이스를 활용해 순서대로 빌더에게 지시를 내리고,

최종적으로 완성된 객체를 반환받는다.

이렇게 함으로써 객체 구성 방법을 바꾸더라도 Builder 구현만 교체하면 되므로,

코드의 가독성과 확장성이 높아진다.

실제 사례로 복잡한 문서 생성기에서 Builder를 활용하여

HTML, PDF 등 서로 다른 포맷의 문서를 생성할 수 있다.

클라이언트는 Builder를 선택하고 Director에게 작업을 맡기면

일련의 과정 후 원하는 형태의 결과물을 얻을 수 있다.

5) 프로토타입(Prototype) 패턴

프로토타입 패턴은 기존 객체를 복제함으로써 새로운 객체를 생성하는 패턴이다.

직접 new로 객체를 생성하는 대신, 원형이 되는 객체(Prototype)를 미리 하나 만들어 놓고

필요한 시점에 이를 복사(clone)하여 사용한다.

이러한 방식은 객체 생성 비용이 큰 경우(예: 복잡한 초기화 과정을 거쳐야 하는 객체)나

객체의 종류가 너무 많아 클래스로 모두 정의하기 어려울 때 유용하다.

프로토타입 패턴을 구현하려면 복제 기능을 갖춘 인터페이스(Cloneable 등)를 활용하거나,

객체 스스로가 자기 복제를 수행하는 메서드를 제공하게 한다.

복제 시 얕은 복사(shallow copy)와 깊은 복사(deep copy)를 적절히 선택해야 하며,

복제된 객체를 원본과 독립적으로 사용할 수 있도록 관리해야 한다.

프로토타입 패턴의 예로, 게임에서 다양한 몬스터를 생성할 때 기본 몬스터 객체 하나를 만들어 놓고

상태만 변경하여 복제함으로써 성능을 높이는 경우를 들 수 있다.

---

2. 구조 패턴 (Structural Patterns)

구조 패턴은 객체나 클래스들을 조합하여 더 큰 구조를 만드는 패턴들로,

객체들 간의 관계를 조직화하고 인터페이스를 단순화하는 데 초점을 맞춘다.

대표적인 구조 패턴에는 어댑터, 브리지, 컴포지트, 데코레이터, 퍼사드, 플라이웨이트, 프록시 패턴 등이 있다.

1) 어댑터(Adapter) 패턴

어댑터 패턴은 호환되지 않는 두 개념이나 인터페이스를 이어주는 중간 변환기 역할을 하는 패턴이다.

기존 클래스의 인터페이스를 클라이언트에서 기대하는 다른 인터페이스로 변환하여,

인터페이스 불일치로 함께 동작하지 못하던 클래스들이 협력할 수 있게 해준다.

구조는 대상(Target) 인터페이스와 이를 구현하는 어댑터(Adapter) 클래스,

그리고 어댑터가 호환시키고자 하는 적응될 클래스(Adaptee)로 구성된다.

현실 세계의 예로, 전기 콘센트의 플러그 형태가 다를 때 사용하는 돼지코 어댑터를 떠올릴 수 있다.

어댑터를 사용하면 기존 코드를 변경하지 않고도

새로운 인터페이스에 맞춰 사용할 수 있어, 재사용성과 유연성이 높아진다.

2) 브리지(Bridge) 패턴

브리지 패턴은 추상화(Abstraction)와 구현(Implementation)을 분리하여

두 요소를 독립적으로 확장할 수 있게 해주는 패턴이다.

즉, 기능 계층과 구현 계층을 따로 만들어 계층 구조를 각각 관리하고, 런타임에 이들을 조합하여 사용한다.

이를 통해 하나의 계층에 변경이 발생해도 다른 계층에 영향을 주지 않아 유지보수성이 향상된다.

구조적으로는 추상 클래스가 구현 객체를 참조하는 형태로 연결되며,

구현부 인터페이스를 변경하지 않고도 새로운 구현을 도입할 수 있다.

예를 들어, 그래픽 화면을 그리는 코드에서 "화면 표현"을 담당하는 부분과

"출력 장치"에 대한 부분(예: 모니터, 프린터 등)을 브리지로 분리하면,

출력 장치를 추가하거나 교체해도 화면 표현 로직을 수정할 필요가 없다.

3) 컴포지트(Composite) 패턴

컴포지트 패턴은 여러 개의 객체를 트리(tree) 구조로 구성하여 부분-전체 계층을 구현하는 패턴이다.

이를 통해 단일 객체와 복합 객체를 클라이언트에서 일관되게 다룰 수 있게 해준다.

컴포지트 패턴의 구조에서는 공통된 추상 구성 요소(Component)가 있고,

리프(Leaf) 객체와 다른 구성 요소를 포함하는 컴포지트(Composite) 객체가 존재한다.

Composite 객체는 자신의 자식들을 관리하며, 클라이언트의 요청을 자식들에게 전달하거나 결과를 취합한다.

이 패턴을 사용하면 폴더-파일과 같은 계층 구조를 편리하게 다룰 수 있는데,

예컨대 폴더 안에 폴더와 파일이 들어있는 계층 구조를 컴포지트 패턴으로 구현하면

폴더와 파일을 동일한 인터페이스로 처리할 수 있어 코드가 단순해진다.

4) 데코레이터(Decorator) 패턴

데코레이터 패턴은 객체를 감싸서(decorate) 새로운 행위를 부여함으로써,

런타임에 동적으로 기능을 확장할 수 있게 해주는 패턴이다.

상속을 사용하지 않고도 객체에 추가 책임을 부여하기 쉽고,

여러 데코레이터를 중첩하여 복합적인 기능 확장도 가능하다.

구조적으로 데코레이터는 원본 객체(Component 인터페이스 구현체)를 포함(composition)하고 있으며,

Component와 동일한 인터페이스를 구현한다.

그리고 필요한 새로운 기능을 추가한 뒤, 나머지 요청은 내부의 원본 객체에 위임하여 처리한다.

Decorator 패턴의 구조를 나타낸 UML 클래스 다이어그램.

Component 인터페이스를 구현한 ConcreteComponent가 기본 기능을 제공하고,

Decorator 추상 클래스를 통해 추가 기능을 덧씌운다.

여러 개의 ConcreteDecorator가 중첩되어 원본 객체의 행위를 확장할 수 있다.

예를 들어 자바의 InputStream에 버퍼링 기능을 추가하는 BufferedInputStream이나,

GUI 컴포넌트에 스크롤바 기능을 추가하는 ScrollDecorator 등이 데코레이터 패턴의 실제 사례이다.
이러한 방식은 상속으로 다양한 기능 조합 클래스를 무수히 만들 필요 없이,

필요한 데코레이터를 조합하여 유연하게 기능을 추가할 수 있다는 장점이 있다.

5) 퍼사드(Facade) 패턴

퍼사드(Facade) 패턴은 복잡한 여러 객체로 구성된 시스템에 단순한 인터페이스를 제공하기 위한 패턴이다.

외부에서 복잡한 라이브러리나 서브시스템을 사용할 때,

퍼사드 객체가 일련의 복잡한 작업을 내부에서 처리하고 간단한 메서드만 노출함으로써 사용성을 높여준다.

구조는 퍼사드 클래스가 시스템의 주요 구성 요소들을 필드로 갖고,

클라이언트의 요청을 받아 적절한 객체들에게 작업을 위임하는 식이다.

이 패턴을 통해 클라이언트 코드는 복잡한 서브시스템의 세부 사항을 몰라도 되고, 결합도가 낮아진다.

현실 세계의 예로, 호텔의 퍼사드 역할을 하는 접수원이 여러 내부 서비스를 대신 처리하여

고객은 접수원에게만 요청하면 되는 경우를 생각할 수 있다.

개발에서 흔히 볼 수 있는 예로는, 여러 모듈로 구성된 API의 단순화된 Facade 클래스나,

복잡한 초기화 절차를 캡슐화한 헬퍼 클래스 등이 있다.

6) 플라이웨이트(Flyweight) 패턴

플라이웨이트 패턴은 많은 수의 객체를 메모리 효율적으로 공유하기 위한 패턴이다.

본질적으로 동일한 객체를 중복으로 생성하지 않고,

공통된 객체를 재사용함으로써 메모리 사용량을 줄이고 성능을 높인다.

구조는 플라이웨이트 팩토리(Flyweight Factory)가 객체 풀(pool)을 관리하면서 이미 생성된 객체를 제공하거나,

없으면 생성하여 풀에 담아둔다.

객체 상태를 내재 상태(intrinsic state: 공유되는 상태)와 외재 상태(extrinsic state: 개별 속성)로 구분하여,

공유되는 부분만 플라이웨이트 객체에 담고 외재 상태는 객체 사용 시 넘겨주는 방식으로 구현하는 것도 특징이다.

예를 들어, 텍스트 편집기에서 문자 객체를 만들 때 동일한 글자는 하나의 객체를 공유하고,

글자의 위치나 스타일과 같은 개별 속성만 따로 관리하도록 하면 방대한 텍스트에서도 메모리를 절약할 수 있다.

이처럼 플라이웨이트 패턴은 대량의 객체 생성으로 인한 비용 문제를 해결하는데 유용하다.

7) 프록시(Proxy) 패턴

프록시 패턴은 어떤 객체에 대한 접근을 제어하기 위해 대리인(Proxy) 객체를 앞세우는 패턴이다.

프록시는 실제 객체(Real Subject)를 대신하여 요청을 받아 처리하거나, 필요에 따라 실제 객체에 요청을 전달한다.

이 때 프록시는 접근 제어, 로깅, 캐싱 등 부가적인 기능을 수행할 수 있다.

구조적으로 Subject 인터페이스를 실제 객체와 프록시가 공유하며,

클라이언트는 실제 객체 대신 프록시에 요청을 보내게 된다.

프록시의 유형에는 가상 프록시(실제 객체 생성을 지연하여 성능 향상),

보호 프록시(접근 권한을 제어), 원격 프록시(다른 주소 공간의 객체와 통신) 등이 있다.

예를 들어, 데이터베이스 연결 객체의 프록시를 만들어 실제 쿼리 실행 전에 연결 풀에서 연결을 가져오거나,

원격 서비스 호출을 로컬 프록시로 제공하여 네트워크 통신을 캡슐화하는 경우 등에 활용된다.

프록시 패턴을 사용하면

실제 객체에 대한 접근 로직을 변경하지 않고도 다양한 부가 기능을 쉽게 추가하거나 변경할 수 있다.

---

3. 행위 패턴 (Behavioral Patterns)

행위 패턴은 알고리즘이나 객체 간 통신 등 객체들의 상호작용과 책임 분배에 관련된 디자인 패턴들이다.

주요 행위 패턴으로는 책임 연쇄, 커맨드, 인터프리터, 이터레이터, 미디에이터, 메멘토, 옵저버, 상태, 전략, 템플릿 메서드, 방문자 패턴 등이 있다.

1) 책임 연쇄(Chain of Responsibility) 패턴

책임 연쇄 패턴은 하나의 요청을 둘 이상의 객체가 처리할 수 있는 가능성을 두고,

요청을 받는 객체들을 연쇄 형태로 묶어 순차적으로 전달하는 패턴이다.

요청을 처리하는 기회를 체인에 연결된 각 객체가 순서대로 갖게 되며, 어떤 객체가 처리를 맡으면 체인이 종료된다.

이 방식은 발신자와 수신자의 결합도를 줄여주며, 여러 처리 객체 중 누가 처리할지 모르는 상황에서 유연하게 대처할 수 있다.

예를 들어 고객 지원 시스템에서 문의 사항이 들어오면 1차 지원자가 처리하고,

해결 못 하면 상위 지원자에게 넘기는 과정을 책임 연쇄로 구현할 수 있다.

2) 커맨드(Command) 패턴

커맨드 패턴은 요구 사항을 캡슐화하여 요청 자체를 객체로 표현하는 패턴이다.

실행될 기능을 클래스로 만들어 주어진 여러 기능을 실행할 수 있는 재사용성 높은 호출자(Invoker)를 설계할 수 있다.

커맨드 객체는 실행될 구체 동작(리시버와 실행 메서드)을 알고 있으며,

execute() 등의 공통 인터페이스로 호출되기 때문에 클라이언트는 구체적인 실행 내용을 몰라도 된다.

이 패턴을 이용하면 작업 취소(undo), 요청 저장/큐잉 등의 기능도 구현하기 쉽다.

예를 들어, GUI 버튼 클릭 동작을 커맨드 객체로 만들어 Undo/Redo 기능을 지원하거나,

작업 내역을 기록하는 로깅 시스템 등에 활용할 수 있다.

3) 인터프리터(Interpreter) 패턴

인터프리터 패턴은 간단한 언어 또는 문법에 대한 해석기를 정의하는 패턴이다.

복잡한 알고리즘보다는 특정 도메인에 특화된 미니 언어(예: 정규표현식, 수식 계산 등)의

문법 규칙을 클래스로 정의하고, 입력된 문장을 해석(interpret)하는 구조를 제공한다.

인터프리터 패턴에서는 문법의 각 규칙을 나타내는 구조체(NonterminalExpression)와 실제 값을 표현하는 말단 표현(TerminalExpression) 클래스들이 구성되고, 이들로 구성된 구문 트리를 해석하는 방식으로 구현된다.

사용 예로 수학 수식 파서를 들 수 있는데, 수식의 BNF 문법에 따라 각 연산자마다 클래스를 만들고,

주어진 수식을 해석하여 결과를 계산할 수 있다.

다만 인터프리터 패턴은 문법이 복잡해질수록 클래스 수가 급증할 수 있어, 비교적 단순한 경우에 적용하는 것이 일반적이다.

4) 이터레이터(Iterator) 패턴

이터레이터 패턴은 집합 객체(컬렉션)의 내부 구조를 노출하지 않고도 그 요소들을 순차적으로 접근할 수 있게 해주는 패턴이다.

컬렉션 별로 서로 다른 순회 방법을 사용하더라도, 표준화된 Iterator 인터페이스(hasNext(), next() 등)를 구현함으로써

일관된 방식으로 요소들을 탐색할 수 있다.

이터레이터를 사용하면 컬렉션의 구현이 변경되어도 반복 처리 로직은 변경할 필요가 없고,

여러 종류의 컬렉션(리스트, 트리 등)을 동일한 방법으로 다룰 수 있다는 장점이 있다.

Java의 Iterator나 파이썬의 이터레이터 프로토콜(__iter__, __next__)이 이러한 패턴에 해당하며,

foreach 문 등이 내부적으로 이터레이터 패턴을 활용한 사례이다.

5) 미디에이터(Mediator) 패턴

미디에이터 패턴은 여러 객체들이 복잡한 상호작용을 하는 상황에서

중재자(Mediator) 객체가 통제와 조정을 맡도록 하는 패턴이다.

각 객체(Colleague)는 미디에이터와만 통신하고 서로 직접 참조하지 않기 때문에

객체들 간의 의존성을 줄이고 관계를 단순화할 수 있다.

미디에이터는 동료 객체들 사이에서 발생하는 이벤트나 요청을 받아 적절히 전달하거나,

추가 로직을 수행함으로써 협력 작업을 조정한다.

GUI에서 여러 컴포넌트들의 상호 작용(예: 입력 폼에서 필드들 간의 활성/비활성 제어)을 미디에이터로 구현하면,

컴포넌트들이 직접 서로를 호출하지 않고 미디에이터를 통해 상호작용하게 하여 결합도를 낮출 수 있다.

6) 메멘토(Memento) 패턴

메멘토 패턴은 객체의 상태를 캡처하여 나중에 복원할 수 있도록 하는 패턴이다.

객체의 내부 상태 정보를 메멘토(Memento) 객체로 저장해 두었다가, 필요 시 원본 객체의 상태를 그 시점으로 되돌릴 수 있다.

이때 메멘토는 객체의 캡슐화를 깨뜨리지 않도록 내부 상태를 저장하지만 외부에는 그 내용을 감추는 것이 중요하다.

보통 Originator(원본 객체), Memento, Caretaker(메멘토 보관자) 삼자로 구성되며,

Originator가 메멘토를 만들고 복원하는 역할을 한다.

메멘토 패턴은 되돌리기(undo) 기능이나 시행착오 지원(체스 게임의 되돌리기 등)에 유용하게 쓰인다.

예를 example, 텍스트 에디터에서 편집 기록을 메멘토로 저장해두면

사용자가 실행 취소(undo)를 요청할 때 마지막 저장 상태로 복원할 수 있다.

7) 옵저버(Observer) 패턴

옵저버 패턴은 한 객체의 상태 변화 시, 의존성이 있는 다른 객체들에게 자동으로 알림이 전달되어 갱신이 이루어지도록 하는 패턴이다. 관찰 대상(Subject)이 있고 다수의 관찰자(Observer)가 등록된 형태로, Subject의 상태가 변하면 각각의 Observer에게 통지(Notification)가 가서 객체들의 상태를 동기화한다. 이처럼 일대다(1:N) 의존 관계를 관리함으로써, 객체 사이의 이벤트 기반 느슨한 결합을 구현할 수 있다. 예를 들어, GUI 버튼(Subject) 클릭 시 여러 리스너(Observer) 객체들이 이벤트를 받아서 동작을 수행하거나, 데이터 모델(Subject)의 변경을 화면(View)들이 감지하여 업데이트하는 구조가 옵저버 패턴에 해당한다. 자바의 java.util.Observer/Observable(현재는 Deprecated)이나 이벤트 리스너 구조, C#의 이벤트 델리게이트 등이 대표적인 활용 사례다.

8) 상태(State) 패턴

상태 패턴은 객체의 내부 상태에 따라 행위가 변경되도록 설계하는 패턴이다.

보통 상태를 표현하는 여러 개의 상태 클래스들이 있고,

원본 객체(Context)가 현재 상태를 참조하여 자신의 동작을 위임하는 방식으로 구현된다.

즉, 상태를 객체화하고 캡슐화하여, 상태 전환에 따른 행위 변화를 코드 분기 없이 구현할 수 있다.

Context는 상태 변화가 필요하면 내부의 현재 상태 객체를 다른 것으로 바꾸기만 하면 된다.

이 패턴은 상태에 따라 조건문이 많은 코드를 객체 지향적으로 개선하는 데 효과적이다.

예를 들어, 문서 편집기에서 편집 모드와 미리보기 모드에 따라 키 입력에 대한 동작이 달라지는 경우,

상태 패턴으로 각 모드의 동작을 분리하여 구현할 수 있다.

또는 게임 캐릭터가 '평상시', '분노', '은신' 등의 상태에 따라 공격력이 변하거나 행동이 달라지는 로직도

상태 패턴으로 관리하면 깔끔하다.

9) 전략(Strategy) 패턴

전략 패턴은 서로 교환 가능한 알고리즘(전략)들을 정의하고 캡슐화하여,

런타임에 필요에 따라 알고리즘을 선택해서 사용할 수 있게 해주는 패턴이다.

동일한 문제를 해결하는 여러 방법이 있을 때,

각각을 별도 클래스(Concrete Strategy)로 구현하고 공통 인터페이스(Strategy)를 정의한다.

클라이언트는 전략을 주입받거나 설정함으로써, 코드 수정 없이도 실행 중에 다른 전략으로 교체할 수 있다.

이로써 알고리즘을 사용하는 코드와 구현을 분리하여 변경에 유연하고 확장에 용이한 구조를 얻는다.

예를 들어, 정렬 알고리즘을 상황에 따라 다르게 적용해야 하는 경우,

SortStrategy 인터페이스 아래에 QuickSort, MergeSort 등을 구현해 두고

데이터 양이나 상태에 따라 전략 객체를 바꿔 끼울 수 있다.

Strategy 패턴의 UML 클래스 다이어그램.

Strategy 인터페이스를 통해 여러 구체 전략(ConcreteStrategyA, ConcreteStrategyB)을 교환 가능하게 정의하고,

Context는 런타임에 하나의 전략을 선택하여 사용한다.

10) 템플릿 메서드(Template Method) 패턴

템플릿 메서드 패턴은 알고리즘의 골격을 정의하고, 일부 단계의 구현을 서브클래스에 위임하는 패턴이다.

즉, 상위 클래스에 템플릿이 되는 메서드(Template Method)를 만들어 일련의 작업 흐칙을 정의하고,

그 중 변경 가능한 부분은 추상 메서드나 훅(hook) 메서드 형태로 남겨두어 하위 클래스에서 구체 구현한다.

이 방식으로 알고리즘의 구조는 그대로 유지하면서 세부 단계 구현을 다양화할 수 있고,

코드의 중복을 줄이며 공통 로직은 상위 클래스에서 관리할 수 있다.

예를 들어, 파일을 읽고 파싱하여 데이터를 출력하는 템플릿 메서드를 상위 클래스에 만들고,

파일 포맷별로 파싱 방식만 하위 클래스에서 구현하도록 하면,

전체 흐름은 변경하지 않으면서도 CSV, JSON, XML 등 다양한 포맷에 대응할 수 있다.

또 게임 개발에서 게임 루프의 전체 흐름(초기화 -> 업데이트 -> 종료)을 템플릿 메서드로 정의하고,

각 단계의 구체 사항을 서브클래스에서 구현하는 것도 이 패턴의 활용 예이다.

11) 방문자(Visitor) 패턴

방문자 패턴은 객체의 구조와 기능을 분리하여,

구조는 변경하지 않으면서도 새로운 기능을 추가할 수 있도록 해주는 패턴이다.

여러 종류의 객체로 구성된 데이터 구조가 있을 때,

각 객체의 클래스에 변경을 가하지 않고 새로운 연산을 추가하려면 방문자 객체가 각 요소를 방문하며 기능을 수행하게 한다.

구조적으로 방문자 인터페이스(Visitor)와 구체 방문자 클래스들,

요소에 해당하는 데이터 구조의 각 클래스들이 참여한다.

각 요소 클래스는 accept(Visitor) 메서드를 통해 방문자를 받아들이고,

방문자는 각 요소별로 오버로드된 visit(ElementType) 메서드를 구현하여 해당 요소에 대한 연산을 수행한다.

이 패턴을 사용하면 요소 클래스의 수정 없이도 새로운 연산(방문자)을 추가할 수 있다는 장점이 있지만,

요소의 종류가 자주 변경된다면 모든 방문자 클래스를 수정해야 하는 단점도 있다.

방문자 패턴은 컴파일러의 AST 처리, 오브젝트 구조를 순회하며 다양한 처리를 수행하는 로직 등에 응용될 수 있다.

---

5. 결론

디자인 패턴은 소프트웨어 개발자들에게 검증된 설계 지식의 집합을 제공한다.

패턴을 잘 활용하면 코드의 품질과 유지보수성을 높이고, 팀원 간 원활한 소통을 도모할 수 있다.

다만 패턴은 만능 해법이 아니며, 상황에 맞게 적절한 패턴을 선택하고 적용하는 것이 중요하다.

무조건 남용하기보다는 문제의 문맥을 이해한 후 그에 부합하는 패턴을 활용해야 한다.

초보 개발자라 하더라도 자주 쓰이는 디자인 패턴의 개념과 구조를 이해해 두면,

보다 체계적이고 확장 가능한 설계를 하는 데 큰 도움이 된다.

본 포스트에서 다룬 생성, 구조, 행위 패턴들의 예시를 바탕으로 실제 코드에 어떻게 적용할지 고민해 보고 연습해보자.

디자인 패턴을 적극적으로 익혀둔다면 새로운 과제나 복잡한 시스템을 마주했을 때

보다 빠르고 우아하게 문제를 해결할 수 있을 것이다.