디자인 패턴

: 자주 사용하는 설계 형태를 정형화 하여 이를 유형별로 설계 템플릿을 만들어 둔 것.

디자인 패턴을 잘 사용하면 효율성과 재사용성을 높일 수 있으며, 설계 자료를 유형별로 분류하면 개발 기간을 둘이고 유지보수도 매우 쉬워질 수 있다.

디자인 패턴은 알고리즘처럼 프로그램 코드로 변환하여 바로 사용할 수 있는 것은 아니지만 유사한 상황에서 구조적인 문제를 해결할 수 있는 방안을 제시해준다.

 

<디자인 패턴의 장점>

1) 개발자(설계자) 간의 원활한 의사소통

: 여러 디자인 패턴의 특성을 잘 알고 있어 문제해결 시 어떤 디자인 패턴을 사용하면 좋을지 해결책을 논의할 수 있다. 

2) 소프트웨어 구조 파악 용이

: 디자인 패턴의 특성을 잘 알고 있기에 어떤 디자인 패턴이 설계할 때 사용되었는지 알면 소프트웨어 전체구조를 쉽게 파악 가능

3) 재사용을 통한 개발 시간 단축

: 이미 만들어 놓은 디자인 패턴을 사용하므로 개발시간을 단축시킬 수 있음

4) 설계 변경 요청에 대한 유연한 대처

: 사용자의 지속적인 추가 요청, 환경 변화 등의 설계 변경 요청에 쉽고 빠르게 대처 가능

 

<디자인 패턴의 단점>

1) 객체지향 설계/ 구현 위주

: 디자인 패턴은 객체지향 설계/구현에 많이 사용되는데, C언어를 주로 사용하는 구조적 설계/구현에서도 사용할 수 있지만 너무 복잡해서 큰 도움이 되지 않는다.

2) 초기 투자 비용 부담

: 디자인 패턴을 적용 및 설계하면 디자인 패턴을 사용하지 않은 경우보다 초기에 시간과 노력이 많이 든다.

 

 

 

<디자인 패턴의 종류>

1. 스트래티지 패턴 (Strategy Pattern)

: 교환 가능한 행동을 캡슐화 하고 위임을 통해 어떤 행동을 사용할지 결정한다.

 

2. 옵저버 패턴 (Observer Pattern)

: 상태가 변경되면 다른 객체한테 연락을 돌릴 수 있게한다.

 

3. 데코레이터 패턴 (Decorator Pattern)

: 객체를 감싸서 새로운 행동을 제공한다.

 

4. 팩토리 패턴 (Factory Pattern)

: 생성할 구상 클래스를 서브 클래스에서 결정한다.

 

5. 추상 팩토리 패턴 (Abstract Factory Pattern)

: 클라이언트에서 구상 클래스를 지정하지 않으면서도 일군의 객체를 생성할 수 있도록 한다.

 

6. 싱글턴 패턴 (Singleton Pattern)

: 딱 한 객체만 생성되도록 한다.

 

7. 커맨드 패턴 (Command Pattern)

: 요청을 객체로 감싼다.

 

8. 어댑터 패턴 (Adaptor Pattern)

: 객체를 감싸서 다른 인터페이스를 제공한다.

 

9. 퍼사드 패턴 (Facade Pattern)

: 일련의 클래스에 대서 간단한 인터페이스를 제공한다.

 

10. 템플릿 메소드 패턴 (Template Method Pattern)

: 알고리즘의 개별 단계를 구현하는 방법을 서브클래스에서 결정한다.

 

11. 이터레이터 패턴 (Iterator Pattern)

: 컬렉션이 어떤 식으로 구현되어 있는지 드러내지 않으면서도 컬렉션 내에 있는 모든 객체에 대해 반복 작업을 처리할 수 있게 한다.

 

12. 컴포지트 패턴 (Composite Pattern)

: 클라이언트에서 객체 컬렉션과 개발 객체를 똑같이 다룰 수 있도록 한다.

 

13. 스테이트 패턴 (State Pattern)

: 알고리즘의 개별 단계를 구현하는 방법을 서브 클래스에서 결정한다.

 

14. 프록시 패턴 (Proxy Pattern)

: 객체를 감싸서 그 객쳉체에 대한 접근을 제어한다.

 

15. 컴파운드 패턴 (Compound Pattern)

: 반복적으로 생길 수 있는 일반적인 문제를 해결하기 위한 용도로 두 개 이상의 패턴을 결합해서 사용하는 것

 

16. 브리지 패턴 (Bidge  Pattern)

: 구현 뿐만 아니라 추상화된 부분까지 변경시켜야 하는 경우

 

17. 빌더 패턴 (Builder Pattern)

: 제품을 여러 단계로 나눠서 만들 수 있도록 제품 생산 단계들을 캡슐화 할 때

 

18. 역할 사슬 패턴 (Chain Of Responibility Pattern)

: 한 요청을 두 개 이상의 객체에서 처리하고 싶을 때

 

19. 플라이웨이트 패턴 (Flyweight Pattern)

: 어떤 클래스의 인스턴트 한 개만 가지고 여러개의 '가상 인스턴스'를 제공하고 싶을 때

 

20. 인터프리터 패턴 (Interpreter Pattern)

: 어떤 언어에 대한 인터프리터를 만들 때

 

21. 미디에이터 패턴 (Mediator Pattern)

: 서로 관련된 객체 사이의 복잡한 통신과 제어를 한 곳으로 집중시키고자 할 때

 

22. 메멘토 패턴 (Memento Pattern)

: 객체를 이전의 상태로 복구시켜야 하는 경우

 

23. 프로토타입 패턴 (Prototype Pattern)

: 어떤 클래의 인스턴스를 만드는 것이 자원/시간을 많이 잡아먹거나 복잡한 경우

 

24. 비지터 패턴 (Visitor Pattern)

: 다양한 객체에 새로운 기능을 추가해야 하는데 캡슐화가 별로 중요하지 않은 경우