크레이티브 패턴

Creational pattern

소프트웨어 공학에서, 창조적인 디자인 패턴은 상황에 맞는 방식으로 물체를 창조하려고 시도하면서 객체 생성 메커니즘을 다루는 디자인 패턴이다.객체 생성의 기본 형태는 설계 문제를 야기하거나 설계에 복잡성을 가중시킬 수 있다.창조적인 디자인 패턴은 이 객체 창조를 어떻게든 제어함으로써 이 문제를 해결한다.

크리에이티브 디자인 패턴은 두 개의 지배적인 아이디어로 구성되어 있다.하나는 시스템이 어떤 콘크리트 클래스를 사용하는지에 대한 지식을 캡슐화하는 것이다.또 하나는 이러한 구체적인 계층의 사례가 어떻게 만들어지고 결합되는가를 숨기는 것이다.[1]

크리에이티브 디자인 패턴은 더욱 객체-크리에이션 패턴과 클래스-크리에이션 패턴으로 분류되는데, 여기서 객체-크리에이션 패턴은 객체 생성과 클래스-인스턴트레이닝을 다룬다.보다 세부적으로 보면, 객체-크리닝 패턴은 객체 생성의 일부를 다른 객체로 지연시키는 반면, 클래스-크리닝 패턴은 객체 생성을 하위 클래스로 지연시킨다.[2]

크리에이티브 패턴의 일부인 잘 알려진 다섯 가지 디자인 패턴은

  • 추상적 공장 패턴,[3] 즉 객체의 콘크리트 클래스를 지정하지 않고 관련 또는 종속 객체를 생성하기 위한 인터페이스를 제공한다.
  • 동일한 시공 프로세스가 다른 표현을 만들 수 있도록 복잡한 객체의 구조를 표현과 분리하는 빌더 패턴.
  • 클래스가 하위 클래스에 인스턴스화를 연기할 수 있는 공장 방식 [4]패턴
  • 프로토타입 패턴 - 프로토타입 인스턴스를 사용하여 만들 객체의 종류를 지정하고 이 프로토타입을 복제하여 새로운 객체를 생성한다.
  • 클래스가 하나의 인스턴스만 가질 수 있도록 보장하고 클래스에 대한 전역 액세스 지점을 제공하는 싱글톤 패턴.[5]

정의

창조적 패턴은 어떤 시스템을 그것의 물체가 어떻게 생성되고, 구성되고, 어떻게 표현되는지와 분리하는 것을 목표로 한다.그들은 객체 생성의 무엇, 누구, 방법, 시기 측면에서 시스템의 유연성을 증가시킨다.[6]

사용법

현대 소프트웨어 공학은 계급 상속보다 개체 구성에 더 많이 의존하기 때문에, 강조는 하드 코딩하는 행동에서 벗어나 보다 복잡한 행동들로 구성될 수 있는 더 작은 기본 행동들을 정의하는 쪽으로 이동한다.[7]하드 코딩 동작은 설계의 일부를 변경하기 위해 전체 사항을 재정의하거나 재실행해야 하기 때문에 융통성이 없다.또한 하드 코딩은 재사용을 촉진하지 않으며 오류를 추적하는 것을 어렵게 한다.이러한 이유로, 창조적인 패턴은 하드 코딩하는 행동보다 더 유용하다.크리에이티브 패턴은 디자인을 더욱 유연하게 만든다.그들은 그것들을 인스턴스화할 필요가 있는 코드에서 콘크리트 클래스의 명시적인 참조를 제거하는 다른 방법을 제공한다.[8]다시 말해, 그들은 개체와 계층에 대해 독립성을 만들어낸다.

다음과 같은 경우 크리에이티브 패턴을 적용하는 것을 고려하십시오.

  • 시스템은 그것의 목적과 제품이 어떻게 생성되는지와 독립적이어야 한다.
  • 관련 물체 세트는 함께 사용하도록 설계되었다.
  • 클래스 라이브러리 또는 제품의 구현을 숨기고 인터페이스만 표시
  • 독립된 복합 객체의 서로 다른 표현 구성.
  • 클래스는 하위 클래스가 자신이 만든 객체를 구현하기를 원한다.
  • 클래스 인스턴스화는 런타임에 지정된다.
  • 단일 인스턴스가 있어야 하며 클라이언트는 항상 이 인스턴스에 액세스할 수 있다.
  • 인스턴스는 수정하지 않고 확장할 수 있어야 한다.

구조

크리에이티브 패턴 클래스 다이어그램.

아래는 대부분의 크리에이티브 패턴이 공통적으로 가지고 있는 간단한 클래스 다이어그램이다.서로 다른 크리에이티브 패턴은 추가 클래스를 필요로 하며 서로 다른 참여 클래스를 필요로 한다는 점에 유의하십시오.

참가자:

  • 작성자:객체 인터페이스를 선언한다.객체를 반환한다.
  • ConcretateCreator:개체의 인터페이스 구현

예

크리에이티브 설계 패턴의 일부 예는 다음과 같다.

  • 추상적 공장 패턴: 클래스는 객체를 직접 만드는 대신 공장 객체에 필요한 객체를 요청함
  • 공장 방식 패턴: 여러 구현 중 하나를 선택하여 특정 유형의 객체 생성을 중앙 집중화
  • 빌더 패턴: 동일한 시공 프로세스가 서로 다른 표현을 만들 수 있도록 복합 객체의 구조를 표현에서 분리
  • 종속성 주입 패턴: 클래스는 개체를 직접 생성하는 대신 인젝터로부터 필요한 개체를 수락함
  • 게으른 초기화 패턴: 객체의 생성, 값 계산 또는 다른 값비싼 프로세스를 처음 필요할 때까지 지연시키는 전술
  • 객체 풀 패턴: 더 이상 사용되지 않는 객체를 재활용하여 값비싼 리소스 구입 및 릴리스 방지
  • 프로토타입 패턴: 프로토타입 인스턴스에 의해 생성될 객체 유형이 결정될 때 사용되며, 프로토타입은 새로운 객체를 생성하기 위해 복제된다.
  • Singleton 패턴: 클래스의 인스턴스화를 하나의 개체로 제한

참고 항목

참조

  1. ^ Gamma, Erich; Helm, Richard; Johnson, Ralph; Vlissides, John (1995). Design Patterns. Massachusetts: Addison-Wesley. p. 81. ISBN 978-0-201-63361-0. Retrieved 2015-05-22.
  2. ^ Gamma, Erich; Helm, Richard; Johnson, Ralph; Vlissides, John (1995). Design Patterns. Massachusetts: Addison-Wesley. ISBN 978-0-201-63361-0. Retrieved 2015-05-22.
  3. ^ Freeman, Eric; Freeman, Elisabeth; Sierra, Kathy; Bates, Bert (2004). Hendrickson, Mike; Loukides, Mike (eds.). Head First Design Patterns. California: O'Reilly Media. p. 156. ISBN 978-0-596-00712-6. Retrieved 2015-05-22.
  4. ^ Freeman, Eric; Freeman, Elisabeth; Sierra, Kathy; Bates, Bert (2004). Hendrickson, Mike; Loukides, Mike (eds.). Head First Design Patterns. California: O'Reilly Media. p. 134. ISBN 978-0-596-00712-6. Retrieved 2015-05-22.
  5. ^ Freeman, Eric; Freeman, Elisabeth; Sierra, Kathy; Bates, Bert (2004). Hendrickson, Mike; Loukides, Mike (eds.). Head First Design Patterns. California: O'Reilly Media. p. 177. ISBN 978-0-596-00712-6. Retrieved 2015-05-22.
  6. ^ Judith, Bishop (2007). C# 3.0 Design Patterns. California: O'Reilly Media. p. 336. ISBN 978-0-596-52773-0. Retrieved 2015-05-22.
  7. ^ Gamma, Erich; Helm, Richard; Johnson, Ralph; Vlissides, John (1995). Design Patterns. Massachusetts: Addison-Wesley. p. 84. ISBN 978-0-201-63361-0. Retrieved 2015-05-22.
  8. ^ Gamma, Erich; Helm, Richard; Johnson, Ralph; Vlissides, John (1995). Design Patterns. Massachusetts: Addison-Wesley. p. 85. ISBN 978-0-201-63361-0. Retrieved 2015-05-22.