Intro.디자인 패턴 정리 ( Design pattern )

디자인 패턴의 정의

 

-프로그래머들이 유용하다가 생각되는 객체들간의 일반적인 상호작용 방법들을 모은 목록

-어떤 분야에서 계속 반복해서 나타나는 문제들을 해결해 온 전문가들의 경험을 모아서 정리한 것

-여러 번 반복하여 사용할 수 있는 문제에 대한 솔루션을 기술한 것(Gamma)

디자인 패턴의 역사

 

-디자인 패턴의 연구는 1990년대 초반 Erich Gamma[1992]에 의해 시작

-일반적으로 GoF(Gang of Four)의 분류가 많이 활용되고 있음.

-23개의 일반적이고 유용한 패턴들을 제공

-패턴을 사용하게 되면 이미 검증된 해결방안을 계속 재사용할 수 있음.

패턴의 구성요소(GoF)

 

-패턴의 이름과 구분: 패턴을 부를 때 사용하는 이름과 패턴의 유형

-문제 및 배경: 패턴이 사용되는 분야 또는 배경, 해결하는 문제를 의미

-솔루션: 패턴을 이루는 요소들, 관계, 협동(Collaboration) 과정

-사례: 간단한 적용 사례

-결과: 패턴을 사용하면 얻게 되는 이점이나 영향

-샘플 코드: 패턴이 적용된 원시코드

디자인 패턴의 종류

생성 패턴

 

-Factory Method: 입력 데이터에 따라 Abstract한 부모 클래스의 여러 서브클래스 중 어떤 것을 반환할지를 결정하는 간단한 클래스 제공

-Abstract Factory: 관련된 객체들의 Family중 하나를 생성하고 반환하는 인터페이스 제공

-Builder: 복잡한 객체의 생성을 표현과 분, 프로그램의 필요에 따라 여러 다른 표현 생성

-Prototype: 새로운 인스턴스를 복사하거나 복제하는 인스턴스화된 클래스를 제공, 인스턴스는 Public 메소드 사용하여 테일러링 가능

-Singleton: 하나 이상의 인스턴스가 생성되지 않는 클래스를 의미, 이러한 인스턴스에 접근하기 위한 하나의 Global 접근 포인트 제공

 

구조 패턴

 

-Adapter: 하나의 클래스 인터페이스가 다른 클래스들과 합쳐지는 데 이용

-Bridge: 객체의 구현과 인터페이스 분리시 서로 영향을 미치지 않으면서 변화시키려고 할 때 사용

-Composite: 객체를 새로 만들고 각각의 객체는 단순 한 개의 객체이거나 Composition된 객체

-Decorator: 동적으로 객체에 신뢰성을 추가할 때 사용

-Facade: 하나의 클래스로 모든 서브시스템을 컨트롤 하고자 할 때 사용

-Flyweight: 객체 공유를 위해서 각 인스턴스는 그 자신의 상태를 내부에 저장하지 않고 외부에 저장. 클래스의 인스턴스들이 메모리에 많이 존재할 경우 메모리 공간을 절약하여 효율적으로 사용

-Proxy: 복잡한 객체의 루틴을 대신 호출해주는 간단한 객체 제공

행위 패턴

-Command: SW 명령 실행을 표현하는 간단한 객체 구성, 로그 작성, Undo가 가능한 명령 작성

-Chain of Responsibility: 요청이 인식될 때까지 체인을 따라 요청한 객체에서 다음 객체로 전달, 객체들간 커플링 최소화

-Mediator: 모든 객체의 레퍼런스를 간직하고 있는 별도의 클래스, 이를 통해 하나로부터 여러 개로 통신 정의

-Interpreter: 프로그램에 어떻게 자체 언어를 내장할 것인가에 대한 정의 제공

-Iterator: 클래스 사이에 데이터 리스트를 전달하는 방법 정의

-Observer: 여러 개의 객체들의 변화 감지 방법 정의

-State: 객체의 내부 상태가 변화되었을 때 각자의 행동을 변화시키는 방법 정의

-Strategy: 클래스내부의 알고리즘 캡슐화

-Template: 알고리즘의 추상 정의 제공

-Visitor: 클래스를 침해하지 않고 폴리모피즘 더함

중요한 세가지 규칙

-구현(Implementation)클래스가 아니라, 인터페이스(Interface)를 가지고 프로그래밍

• 인터페이스 클래스의 메소드를 바탕으로 호출
• 인터페이스를 구현한 클래스의 내부 변화(비즈니스 로직 변경)에 영향을 받지 않음

-상속(Inheritance)이 아니라 위임(Delegation)을 사용

• 불필요한 수퍼클래스의 속성 및 메소드를 상속받음
• 상속의 경우 컴파일시 수퍼클래스와 서브클래스의 구조가 결정됨
• 위임의 경우 런타임시 필요한 클래스를 사용

-커플링(Coupling) 최소화

• God Class를 만들지 않음
• 한 클래스의 변화가 전체클래스를 변화되지 않게 해야 함

이제부터 써내려갈 디자인 패턴은 이분의 블로그를 많이 활용하여 정리 할 것입니다.

출처 :  http://gyrfalcon.tistory.com/