목차

디자인 패턴

소프트웨어 공학에서 소프트웨어 디자인 패턴이란 소프트웨어를 디자일할 때 자주 발생할 수 있는 문제들에 대한 일반적이고 재사용 가능한 해결방법이다. 디자인 패턴은 완벽히 구체화된 설계도가 아니다. 즉, 그 즉시 소스코드로 바로 작성될 수 있는 것이 아니다. 디자인 패턴은 애플리케이션이나 시스템을 설계할 때 발생할 수 있는 일반적인 문제에 대해 사용할 수 있는 공식화되어 있는 모범 예시에 가깝다. 디자인 패턴들은 생성, 구조, 행동, 동시실행 패턴으로 크게 4가지로 분류할 수 있다. 이 포스트에서는 대표적인 생성, 구조, 행동 패턴에 대해서 서술하고자 한다.

생성 패턴 (Creational patterns)

  1. 싱글톤 패턴 Singleton pattern 클래스에 인스턴스가 하나만 있도록 하고, 이에 대한 글로벌 액세스 지점을 제공한다.

  2. 팩토리-메서드 패턴 Factory Method pattern 단일 개체를 만들기 위한 인터페이스를 정의하되, 인스턴스화는 해당 클래스의 하위 클래스에서 결정하도록 한다. 이 패턴을 사용하면 클래스가 인스턴스화를 하위 클래스에게 전담시킬 수 있다.

  3. 추상 팩토리 패턴 Abstract Factory pattern 구체적인 클래스를 지정하지 않고, 관련된 객체나 종속 객체를 생성할 수 있는 인터페이스를 제공한다.

구조 패턴 (Structural patterns)

  1. 어댑터 패턴 Adapter(Wrapper) pattern 외부 클래스의 인터페이스를 클라이언트가 기대하는 형태의 다른 인터페이스로 변환한다. 어댑터는 호환되지 않는 인터페이스를 위한 징검다리 역할을 하여, 기존의 클래스와 함께 작동하도록 한다.

  2. 프록시 패턴 Proxy pattern 다른 객체에 대한 엑세스를 제어할 대리자 혹은 place holder를 제공한다.

  3. 퍼사드 패턴 Facade pattern 하위 시스템을 더 쉽게 사용할 수 있도록 하는 상위 수준 인터페이스를 정의한다. (FYI: facade(퍼사드)는 프랑스어로 건물의 정면을 뜻한다.)

  4. 데코레이터 패턴 Decorator pattern 동적으로 동일한 인터페이스를 사용하는 객체에 추가 책임을 부여한다. 데코레이터 패턴은 유연하게 기능을 확장하기 위해 사용된다.

  5. 컴포짓 패턴 Composite pattern 부분-전체 계층구조를 나타내기 위해 객체를 트리 구조로 구성한다. 컴포짓 패턴은 클라이언트가 개별 객체와 복합 객체를 동일하게 처리하도록 한다.

행동 패턴 (Behavioural patterns)

  1. 전략 패턴 Strategy pattern 알고리즘의 집합을 정의하고, 각 알고리즘을 캡슐화하고, 각각을 서로 대체할 수 있도록 한다. 알고리즘을 사용하는 클라이언트와 독립되어 알고리즘이 변화할 수 있도록 한다.

  2. 상태 패턴 State pattern 객체의 내부 상태가 변경되었을 때 그 객체의 행동양식을 변화시킨다. 이는 상위 클래스의 매개변수를 갖는 객체가 해당 클래스의 하위 클래스 A에서 다른 하위 클래스 B로 변경하는 방식으로 구현할 수 있다.

  3. 커맨드 패턴 Command pattern 요청을 하나의 객체로 캡슐화하고, 요청을 큐에 넣거나 로깅하는 것을 가능하게 한다. 또한 커맨드 패턴을 이용하면 실행했던 작업을 취소하는 것도 가능해진다.

  4. 템플릿 메서드 패턴 Template Method pattern 알고리즘의 골격만 정의하고, 일부 단계는 하위 클래스에서 구현하도록 한다. 템플릿 메서드 패턴을 사용하면 알고리즘의 전체 골격을 변경하지 않고, 하위 클래스에서 알고리즘의 일부 단계를 재정의할 수 있다.

  5. 중재자 패턴 Mediator pattern 객체들의 상호 작용 방법을 정하는 객체를 정의한다. 중재자 패턴은 객체들이 서로를 직접 참조하지 않도록 하여 느슨한 결합을 만들고, 이를 통해 각 객체의 상호작용이 독립적으로 변화할 수 있도록 한다.

참고자료