디자인 패턴은 무엇이며 어떤 것들이 있을까?
디자인 패턴 (Design Pattern)
--
디자인 패턴은
소프트웨어 설계에서 자주 발생하는 문제들을 해결하기 위한 일종의 "표준화된 해결 방법"이다.
(프로그램을 설계할 때 발생했던 문제점들을 특정 방법을 통해 해결할 수 있도록 하나의 "규약", "템플릿" 형태)
특징
- 주로 객체지향 프로그래밍에서 사용한다.
- 코드를 더욱 유지보수하기 쉽고, 확장 가능하게 만든다.
- 주로 객체 생성, 구조 설계, 객체 간 상호작용 등을 효과적으로 처리하는 방법이 있다.
- 다른 개발자들과 더욱 쉽게 소통이 가능해지며, 시스템을 이해하는 데 도움을 준다.
즉, 프로그램 구조를 체계적이고 재사용 가능하게 만들며, 개발자들과 소통하기 편리해진다.
디자인 패턴을 사용하면 왜 소통이 편리해지고, 시스템을 이해하는 데 도움을 줄까?
1. 공통된 용어
디자인 패턴에는 모두 이름이 붙여져 있어, 사용한 디자인 패턴의 이름을 말하면
어떠한 문제를 해결하려고 했는지, 어떤 구조를 가지는지 등 바로 이해할 수 있게 된다.
2. 공통된 설계
디자인 패턴은 이미 수많은 개발자들 사이에서 검증된 설계 방법으로, 사용한 디자인 패턴을 말하면
해당 패턴이 어떤 방식으로 동작할지 미리 알 수 있다.
3. 일관성 있는 코드 구조
디자인 패턴을 사용하면 코드 구조에 일관성이 생긴다.
만약 같은 문제를 해결하기 위해 다른 개발자들이 각기 다른 방식으로 설계하는 것보다,
모두가 이미 알려진 패턴을 사용하게 되면 코드의 구조를 예측할 수 있다.
4. 가독성과 유지보수성
디자인 패턴은 문제를 해결하기 위한 최적의 설계를 제공하기 때문에,
코드를 더 읽기 쉽고 이해하기 쉽게 만든다.
5. 문제 해결에 대한 공통적인 접근 방식
같은 문제를 접했을 경우 이전과 동일한 방식으로 해결할 수 있다.
이를 통해 서로 다른 해석이나 오해를 줄이고 일관된 해결 방식을 기대하여, 의사소통이 편해진다.
디자인 패턴은 크게 3가지로 분류된다.
- 생성 (Creational)
- 구조 (Structural)
- 행위 (Behavioral)
--
생성 패턴 (Creational)
--
생성 패턴은
객체를 생성하는 방법과 관련된 패턴으로,
클래스 정의와 객체 생성 방식을 "구조화", "캡슐화" 등을 수행하여
객체 생성 과정을 단순화하거나, 복잡한 객체 생성을 쉽게 동작하도록 도와준다.
(객체 생성 과정을 클라이언트 코드로부터 분리한다.)
객체를 생성하는 코드를 클라이언트 코드와 분리하여,
클라이언트에서는 객체가 어떻게 생성되는지에 신경 쓰지 않아도 되도록 하는 것이다.
객체를 생성하려면 "new" 키워드로 직접 객체를 생성해야 하지만
매번 "new" 키워드를 사용하면 유연하지 않고 복잡한 코드가 중복될 가능성이 있다.
그래서 객체 생성 로직은 다른 곳에서 "캡슐화"하여 클라이언트가 해당 부분을 몰라도 객체를 만들 수 있도록 한다.
비유하자면
식당에 들어간 손님(클라이언트)은 요리사가 요리(객체)를 어떻게 만드는지 알 필요 없이
원하는 요리(객체)만 골라 식사하면 되는 것이다.
생성 패턴 종류
- 싱글톤 패턴 (Singleton)
클래스의 객체는 단 하나만 생성할 수 있으며, 해당 객체는 전역적으로 접근하여 공유할 수 있게 한다. - 팩토리 메서드 패턴 (Factory method)
객체의 기본 틀은 부모 클래스에서, 구체적인 객체 구현은 자식 클래스에서 정의하여,
객체 생성에 관한 것은 자식 클래스에서 결정하여 부모 클래스는 객체 생성 과정을 신경 쓰지 않아도 된다. - 추상 팩토리 패턴 (Abstract Factory)
관련된 객체들의 집합을 생성하는 인터페이스를 사용한다. - 빌더 패턴 (Builder)
복잡한 객체 생성 과정을 단계별로 나누고, 최종적으로 객체를 생성하는 것을 목표로,
각 역할을 가진 객체로 나누어 다양한 옵션을 가진 객체를 만들 때 유용하게 사용된다. - 프로토타입 패턴 (Prototype)
객체를 복사해서 새로운 객체를 생성하는 것으로,
새로운 객체를 생성하기보다는 기존 객체를 복사해서 사용하고 싶은 경우 유용하다.
--
구조 패턴 (Structural)
--
구조 패턴은
클래스나 객체 간의 관계를 설계하는 패턴으로
여러 객체를 서로 결합하여 더 큰 구조로 만들거나,
객체 간의 관계를 효율적으로 관리하는 것을 도와준다.
비유하자면
무거운 가구를 혼자 옮기지 않고 친구(프록시) or 도구(어댑터)의 도움을 받아
보다 쉽고 효율적으로 가구를 옮길 수 있다.
구조 패턴 종류
- 어댑터 패턴 (Adapter)
서로 호환되지 않는 인터페이스를 가진 클래스를 연결해 주는 방법으로,
기존 코드와 새로운 코드 간의 통합을 쉽게 해 준다. - 브리지 패턴 (Bridge)
추상화와 구현부를 분리하여 각자 독립적으로 변화할 수 있게 한다. - 컴포지트 패턴 (Composite)
객체를 트리 구조로 만들어 개별 객체와 그 객체들의 집합을 동일하게 다룰 수 있도록 한다. - 데코레이터 패턴 (Decorator)
객체에 동적으로 새로운 기능을 추가할 수 있도록 한다.
상속 대신에 컴포지션을 사용하여 기능을 확장할 때 사용된다. - 퍼사드 패턴 (Facade)
복잡한 시스템의 인터페이스를 단순화하여 제공하는 방법으로,
복잡한 서브 시스템을 쉽게 사용할 수 있도록 하나의 통합된 인터페이스를 제공한다. - 플라이웨이트 패턴 (Flyweight)
다수의 객체를 공유하여 메모리를 절약하는 방법으로,
동일한 데이터를 가진 객체들을 공유해서 메모리 사용량을 줄이고 싶은 경우 사용된다. - 프록시 패턴 (Proxy)
다른 객체에 대한 접근을 제어하는 방법이다.
--
행위 패턴 (Behavioral)
--
행위 패턴은
객체 간의 상호작용이나 책임(역할) 분담을 다루는 패턴으로
객체들이 역할 분담은 어떻게 하고, 서로 어떻게 협력하고, 어떤 식으로 데이터를 주고받을지에 관한 설계를 도와준다.
비유하자면
식당에서 직원(객체)들이
재료 분배 담당, 재료 손질 담당, 굽기 담당, 플레이팅 담당 등의 역할을 나누어
특정 요리(결과)를 완성하기 위해 필요한 직원(객체)들이 협력하여
어떠한 순서로 어떻게 요리를 완성할지 설계하는 것이다.
행위 패턴 종류
- 책임 연쇄 패턴 (Chain of Responsibility)
요청을 처리할 수 있는 객체들이 연결되어 있어, 하나의 객체가 처리하지 못하면 다음 객체로 넘어가는 방법이다. - 커맨드 패턴 (Command)
요청을 객체로 캡슐화하여 요청의 실행과 취소를 관리할 수 있게 하는 방법으로
작업을 나중에 실행하거나, 실행 취소 기능을 제공할 때 유용하다. - 인터프리터 패턴 (Interpreter)
언어의 문법을 정의하고 해석하는 방법으로
특정 문법을 가진 언어나 표현식을 해석할 때 사용된다. - 이터레이터 패턴 (Iterator)
집합 객체의 내부 구조를 노출하지 않고, 그 안의 요소들을 순차적으로 접근할 수 있게 하는 방법이다. - 중재자 패턴 (Mediator)
객체들이 서로 직접 통신하는 대신, 중재자를 통해 상호작용하도록 하여 객체 간의 결합도를 줄이는 방법이다. - 메멘토 패턴 (Memento)
객체의 상태를 저장하고 복원할 수 있게 하는 방법이다. - 옵서버 패턴 (Observer)
한 객체의 상태 변화가 있을 때, 관련된 다른 객체들에게 자동으로 통지하는 방법이다. - 상태 패턴 (State)
객체의 상태에 따라 다른 동작을 수행하는 방법으로
상태 전환을 유연하게 처리하고 싶을 때 유용하다. - 전략 패턴 (Strategy)
알고리즘을 캡슐화하여 런타임에 알고리즘을 교체할 수 있게 하는 방법으로
여러 알고리즘 중 하나를 선택해야 할 때 유용하다. - 템플릿 메서드 패턴 (Template Method)
알고리즘의 구조를 정의하고, 세부 구현은 서브클래스에서 정의하도록 하는 방법이다. - 방문자 패턴 (Visitor)
객체 구조를 변경하지 않고, 각 객체에 대해 새로운 기능을 추가할 수 있게 하는 방법으로
다양한 종류의 객체에 대해 공통적인 작업을 수행해야 할 때 사용한다.
--
'Terminology' 카테고리의 다른 글
[디자인 패턴] 팩토리 메서드 패턴 (Factory Method) (1) | 2024.11.01 |
---|---|
[디자인 패턴] 싱글톤 패턴 (Singleton) (0) | 2024.10.30 |
의존성 주입 (DI, Dependency Injection) (+ IoC, DIP) (0) | 2024.10.27 |
SOLID 원칙 ( 객체 지향 설계 원칙) (1) | 2024.10.26 |
객체지향 프로그래밍 (OOP, Object-Oriented Programming) (0) | 2024.10.25 |