해시넷
디자인패턴
디자인패턴(design pattern) 또는 소프트웨어 디자인 패턴(software design pattern)이란 소프트웨어 공학에서 소프트웨어 디자인은 특정 문맥에서 공통적으로 발생하는 문제에 재사용 가능한 해결책을 말한다. 소프트웨어 디자인 패턴은 소프트웨어 설계에 대한 지식이나 노하우가 문제 유형별로 잘 구체화되어 있을 뿐 아니라, 동일한 문제 유형에 대해서는 그 해결 방법에 대한 지식이나 노하우가 패턴 형태로 충분히 일반화된 것이다. 그렇기에 대부분은 프로그래머가 어플리케이션이나 시스템을 디자인할 때 공통된 문제를 해결하는 데 쓰이는 형식화된 가장 좋은 관행이라고 볼 수 있다.[1]
목차
등장 배경[편집]
건축적 개념으로서의 패턴은 크리스토퍼 알렉산더(1977/79)가 창안하였다. 1987년, 켄트 벡과 워드 커닝햄은 프로그래밍, 구체적으로는 패턴 언어에 패턴을 적용하는 개념에 관한 실험을 시작했으며 그 해 OOPSLA 콘퍼런스에서 자신들의 결과를 제시하였다. 그 뒤 여러 해에 걸쳐 벡과 커닝햄 등은 이 작업을 계속 진행하였다.
디자인 패턴은 이른바 사인방(Gang of Four)(에릭 감마(Erich Gamma), 리처드 헬름(Richard Helm), 랄프 존슨(Ralph Johnson), 존 블리시데스(John Vlissides))이 쓴 Design Patterns: Elements of Reusable Object-Oriented Software라는 책이 1994년 출판된 이후 인기를 끌었다.[1]
구성 요소[편집]
생성 패턴[편집]
생성 패턴 객체를 생성하는 것과 관련된 패턴으로, 객체의 생성과 변경이 전체 시스템에 미치는 영향을 최소화하도록 만들어주어 유연성을 높일 수 있고 코드를 유지하기가 쉬운 편이다. 객체의 생성과 참조 과정을 추상화함으로써 시스템을 개발할 때 부담을 덜어준다.[2]
생성 패턴 종류[편집]
< 생성 패턴 종류 > 이름 설명 singleton 전역 변수를 사용하지 않고 객체를 하나만 생성하도록 하며, 생성된 객체를 어디에서든지 참조할 수 있도록 하는 패턴[3] prototype 기존 객체를 복제함으로써 객체를 생성하는 패턴 builder 생성자에 들어갈 매개 변수가 많든 적든 차례차례 매개 변수를 받아들이고 모든 매개 변수를 받은 뒤에 이 변수들을 통합해서 한 번에 사용하는 패턴[5] Factory Method 객체 생성 처리를 서브 클래스로 분리해 처리하도록 캡슐화하는 패턴[3] abstraction factory(추상 팩토리) 구제적인 클래스에 의존하지 않고 서로 연관되거나 의존적인 객체들의 조합을 만드는 인터페이스를 제공하는 패턴[3]
구조 패턴[편집]
구조 패턴 프로그램 내의 자료구조나 인터페이스 구조 등 프로그램의 구조를 설계하는 데 많이 활용될 수 있는 패턴이다. 클래스나 객체들의 구성(합성)을 통해서 더 큰 구조로 만들 수 있게 해준다. 규모가 큰 시스템은 많은 클래스로 구성되어 복잡한 구조를 갖는다. 이렇게 구조가 복잡하면 수정이 쉽지 않다. 또 수정으로 인한 오류도 많이 발생할 수 있다. 이렇게 복잡한 형태의 구조를 갖는 시스템을 개발하기 쉽게 만들어주는 패턴이 바로 구조 패턴이다. 따라서 구조 패턴을 이용하면 새로운 기능을 가진 복합 객체를 효과적으로 작성할 수 있다.[2]
구조패턴 종류[편집]
< 구조 패턴 종류 > 이름 설명 adapter 한 클래스의 인터페이스를 클라이언트에서 사용하고자 하는 다른 인터페이스로 변환하며, 인터페이스의 호환성 문제 때문에 같이 쓸 수 없는 클래스들도 연결 가능한 패턴[6] composite 여러 개의 객체들로 구성된 복합 객체와 단일 객체를 클라이언트에서 구별 없이 다루게 해주는 패턴[3] bridge 두 개의 다른 계층(하나는 추상, 하나는 구현인 서로 다른 계층의 커플링을 약화시키며 협력은 가능하도록 하는 패턴[7] decorator 객체의 결합을 통해 기능을 동적으로 유연하게 확장할 수 있게 해주는 패턴[8] facade 어떤 서브시스템의 일련의 인터페이스에 대한 통합된 인터페이스를 제공하며, 퍼사드에서 고수준 인터페이스를 정의하기 때문에 서브시스템을 더 쉽게 사용하는 패턴[9] flyweight 데이터를 공유 사용하여 메모리를 절약할 수 있는 패턴[10] proxy 실제 기능을 수행하는 객체 Real Object 대신 가상의 객체 Proxy Object를 사용해 로직의 흐름을 제어하는 디자인 패턴[11]
행위패턴[편집]
행위패턴은 반복적으로 사용되는 객체들의 상호작용을 패턴화한 것으로, 클래스나 객체들이 상호작용하는 방법과 책임을 분산하는 방법을 정의한다. 객체의 기능은 변하지 않지만 일을 처리하는 방법이 달라질 때가 있다. 응용 분야에 따라 행위가 다른 객체로 옮겨 가거나 알고리즘이 대체되는 경우이다. 그런 경우 대부분 상속 개념을 이용해 사용할 수 있다. 행위 패턴은 여러 가지 행위 관련 패턴을 사용하여 독립적으로 일을 처리하고자 할 때 사용한다. 즉 행위 패턴은 메시지 교환과 관련된 것으로, 객체들 간의 행위나 알고리즘 등과 관련된 패턴을 말한다.[2]
행위패턴 종류[편집]
< 행위 패턴 종류 > 이름 설명 template method 어떤 작업을 처리하는 일부분을 서브 클래스로 캡슐화해 전체 일을 수행하는 구조는 바꾸지 않으면서 특정 단계에서 수행하는 내역을 바꾸는 패턴[3] interpreter 문법 규칙을 클래스 화 한 구조로써, 일련의 규칙으로 정의된 언어를 해석하는 패턴[12] iterator 컬렉션 구현 방법을 노출시키지 않으면서도 그 집합체 안에 들어있는 모든 항목에 접근할 수 있는 방법을 제공하는 패턴[13] observer 한 객체의 상태 변화에 따라 다른 객체의 상태도 연동되도록 일대다 객체 의존 관계를 구성하는 패턴[3] strategy 행위를 클래스로 캡슐화해 동적으로 행위를 자유롭게 바꿀 수 있게 해주는 패턴[3] visitor 실제 로직을 가지고 있는 객체(Visitor)가 로직을 적용할 객체(Element)를 방문하면서 실행하는 패턴[14] chain of responsibility (책임 연쇄) 요청 처리가 들어오게 되면 그것을 수신하는 객체가 자신이 처리할 수 없는 경우에는 다음 객체에게 문제를 넘김으로써 최종적으로 요청을 처리 할 수 있는 객체의 의해 처리가 가능하도록 하는 패턴[15] command 실행될 기능을 캡슐화함으로써 주어진 여러 기능을 실행할 수 있는 재사용성이 높은 클래스를 설계하는 패턴[3] mediator 모든 클래스간의 복잡한 로직(상호작용)을 캡슐화하여 하나의 클래스에 위임하여 처리하는 패턴[16] state 객체의 상태에 따라 객체의 행위 내용을 변경해주는 패턴[3] memento 객체의 상태 정보를 저장하고 사용자의 필요에 의하여 원하는 시점의 데이터를 복원할 수 있는 패턴[17]
각주[편집]
- ↑ 1.0 1.1 〈소프트웨어 디자인 패턴〉, 《위키백과》,2019-11-26
- ↑ 2.0 2.1 2.2 〈GOF 디자인 패턴〉, 《네이버 지식백과》, 2015-11-30
- ↑ 3.0 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 〈(Design Pattern) 디자인 패턴 종류〉, 《heejeong Kwon》, 2018-06-06
- ↑ 〈(디자인 패턴) GoF의 디자인패턴 간단 정리.〉, 《Gone》, 2017-04-24
- ↑ 〈(Design pattern) Builder pattern〉, 《원딜레이 Onedelay》, 2019-01-02
- ↑ 〈디자인패턴 - 어댑터 패턴 (adapter pattern)〉, 《JSPark》,2016-06-13
- ↑ 〈브릿지 패턴(Bridge Pattern)〉, 《고관우》, 2019-07-15
- ↑ Heee's Development blog, 〈(Design Pattern) 데코레이터 패턴이란〉, 《heejeong Kwon》, 2018-06-09
- ↑ 〈디자인패턴 - 퍼사드패턴(Facede pattern)〉, 《코딩스타트》, 2019-07-24
- ↑ 〈플라이라이트웨이트 패턴(Flyweight Pattern〉, 《Thinking Different》,2014-01-30
- ↑ 〈프록시 패턴(Proxy Pattern)〉, 《JDM》,2019-04-07
- ↑ 〈(디자인 패턴) 인터프리터 패턴(Interpreter Pattern)〉, 《TevQabs》, 2019-02-15
- ↑ 〈이터레이터 패턴 (iterator pattern)〉, 《_JSPark 》,2016-06-30
- ↑ 〈방문자 패턴 - Visitor pattern〉, 《Jeongjin Kim》,2019-10-29
- ↑ 〈10 역할 사슬 패턴 (Chain Of Responsibility)〉, 《Lkt_Programmer》,2017-09-28
- ↑ 〈중재자 패턴(Mediator Pattern)〉,《고관우》,2019-07-07
- ↑ 〈14 메멘토 패턴 (Memento Pattern)〉,《Lkt_Programmer》,2017-10-20
참고자료[편집]
- 〈소프트웨어 디자인 패턴〉, 《위키백과》, 2019-11-26
- 〈GOF 디자인 패턴〉, 《네이버 지식백과》, 2015-11-30
- Heee's Development Blog, 〈(Design Pattern) 디자인 패턴 종류〉, 《heejeong Kwon》, 2018-06-06
- Not become a consumable., 〈(Design pattern) Builder pattern〉, 《원딜레이 Onedelay》, 2019-01-02
- Gone, 〈(디자인 패턴) GoF의 디자인패턴 간단 정리.〉, 《Gone》, 2017-04-24
- 정리정리정리, 〈디자인패턴 - 어댑터 패턴 (adapter pattern)〉, 《JSPark》, 2016-06-13
- Crocus, 〈브릿지 패턴(Bridge Pattern)〉, 《고관우》, 2019-07-15
- Heee's Development blog, 〈(Design Pattern) 데코레이터 패턴이란〉, 《heejeong Kwon》, 2018-06-09
- 여성게 :: 코딩초보를 위한 코딩초보의 블로깅, 〈디자인패턴 - 퍼사드패턴(Facede pattern)〉, 《코딩스타트》, 2019-07-24
- Thinking Different, 〈플라이라이트웨이트 패턴(Flyweight Pattern〉, 《Thinking Different》, 2014-01-30
- JDM's Blog, 〈프록시 패턴(Proxy Pattern)〉, 《JDM》, 2019-04-07
- 언제나 신입, 〈(디자인 패턴) 인터프리터 패턴(Interpreter Pattern)〉, 《TevQabs》, 2019-02-15
- 정리정리정리2, 〈이터레이터 패턴 (iterator pattern)〉, 《_JSPark》, 2016-06-30
- codinglog, 〈방문자 패턴 - Visitor pattern〉, 《Jeongjin Kim》, 2019-10-29
- 맛있는 프로그래머의 일상, 〈10 역할 사슬 패턴 (Chain Of Responsibility)〉, 《Lkt_Programmer》, 2017-09-28
- crocus, 〈중재자 패턴(Mediator Pattern)〉, 《고관우》, 2019-07-07
- 맛있는 프로그래머의 일상2, 〈14 메멘토 패턴 (Memento Pattern)〉, 《Lkt_Programmer》, 2017-10-20
같이 보기[편집]
