디자인 패턴

1.1 패턴 소개

앞에서 언급했듯이 프로그래머는 프로그램이 작동할 엔터티 목록을 컴파일하는 모델을 설계하여 프로그램 작업을 시작합니다. 프로그램에 엔티티가 많을수록 프로그램이 더 복잡해집니다.

따라서 프로그램의 복잡성을 줄이기 위해 개체의 상호 작용을 표준화하려고 합니다. 그리고 이것은 디자인 패턴 이나 디자인 패턴이 프로그래머에게 많은 도움이 되는 곳입니다 . 영어 디자인 패턴 에서 .

중요한! 러시아어에서 디자인이라는 단어는 일반적으로 그래픽 디자인을 의미하지만 영어에서는 그렇지 않습니다. 영어 단어 디자인은 의미상 "디자인" 및/또는 "장치"라는 단어에 더 가깝습니다. 예를 들어, 엔진의 디자인은 외관이 아니라 내부 구조입니다.

따라서 디자인 패턴은 정확히 디자인 패턴/패턴입니다. "외모"라는 의미로 디자인이라는 단어를 사용하지 않는 것이 좋습니다. 당신은 미래의 소프트웨어 엔지니어이며 당신에게 디자인은 정확히 디자인입니다.

그렇다면 이 디자인 패턴은 무엇일까요? 우선, 디자인 패턴은 표준 문제에 대한 표준 솔루션 입니다 . 훌륭하고 효과적이며 오랜 시간 테스트를 거친 솔루션입니다.

자전거를 설계하라는 요청을 받았다고 가정해 보겠습니다. 바퀴 두 개, 세 개 또는 심지어 다섯 개까지 만들 수 있습니다. 그건 그렇고, 디자인의 새벽에는 그랬습니다. 그러나 오랜 시간 동안 검증된 접근 방식은 두 바퀴입니다. 그러나 현재의 명백한 접근 방식은 고통과 실수를 겪었습니다.

일반적으로 템플릿은 코드로 직접 변환할 수 있는 완전한 솔루션이 아니라 다양한 상황에서 사용할 수 있는 문제에 대한 좋은 솔루션의 예일 뿐입니다.

객체 지향 패턴은 사용할 최종 클래스 또는 애플리케이션 객체를 지정하지 않고 클래스 또는 객체 간의 관계 및 상호 작용을 보여줍니다 .

1.2 디자인 패턴의 역사

70년대에 프로그래머들은 전체 개발 팀이 작업해야 하는 대형 프로그램을 개발해야 하는 필요성에 직면했습니다. 다양한 작업 조직 방법이 시도되었지만 건설 산업이 개발에 가장 큰 영향을 미쳤습니다.

많은 사람들의 작업을 조직하기 위해 건설 업계의 관행과 접근 방식이 사용되었습니다. 그런데 거기에서 어셈블리(빌드), 소프트웨어 개발자(빌더), 아키텍처 개념 등의 용어가 프로그래밍에 들어왔습니다.

그리고 짐작하시겠지만 디자인 패턴 아이디어도 건설 업계에서 가져왔습니다. 패턴의 개념은 The Pattern Language에서 Christopher Alexander가 처음으로 설명했습니다. 도시. 건물. 건설". 이 책에서는 도시 디자인 과정을 설명하기 위해 특별한 언어인 패턴을 사용했습니다.

건설 패턴은 전형적인 시간 테스트를 거친 결정을 설명합니다. 창문은 얼마나 높아야 하는지, 건물에 몇 층이 있어야 하는지, 나무와 잔디밭을 위해 소구역에서 얼마나 많은 면적을 할당해야 하는지 등이 있습니다.

따라서 1994년에 "Object-Oriented Design의 기술"이라는 책이 나온 것은 놀라운 일이 아닙니다. Design Patterns'에는 객체지향 설계의 다양한 문제를 해결하는 23개의 패턴이 포함되어 있습니다.

이 책은 Erich Gamma, Richard Helm, Ralph Johnson 및 John Vlissides의 4명의 저자가 저술했습니다. 책 제목이 너무 길어서 아무도 기억할 수 없었습니다. 따라서 곧 모든 사람들이 "4 인조 책", 즉 "4 인조 책" , 심지어 "GoF 책"이라고 부르기 시작했습니다 .

그 이후로 다른 디자인 패턴이 발견되었습니다. "패턴" 접근 방식은 프로그래밍의 모든 영역에서 인기를 얻었으므로 이제 개체 디자인 외부에서 모든 종류의 패턴을 찾을 수 있습니다.

중요한! 패턴은 매우 독창적인 솔루션이 아니라 반대로 자주 발생하는 동일한 문제에 대한 일반적인 솔루션입니다. 검증된 좋은 솔루션.

1.3 패턴 목록

많은 프로그래머는 평생 동안 단 하나의 패턴을 배우지 않았지만 패턴을 사용하는 데 방해가 되지는 않습니다. 앞에서 말했듯이 패턴은 오랜 시간 테스트를 거친 좋은 솔루션이며 프로그래머가 바보가 아니라면 경험을 통해 직접 그러한 솔루션을 찾습니다.

그런데 이미 이런 길을 가고 경험과 삶의 지혜의 정수로 책을 쓴 사람들이 있는데 왜 수십 번의 시행착오를 거쳐 최적의 해결책에 도달하는가?

렌치로 못을 박을 수 있는데 왜? 열심히 노력하면 드릴을 사용할 수도 있습니다. 그러나 악기를 의식적으로 잘 소유하는 것이 바로 전문가와 아마추어를 구별하는 것입니다. 그리고 전문가는 드릴의 주요 기능이 전혀 없다는 것을 알고 있습니다. 그렇다면 왜 패턴을 알아야 할까요?

• 검증된 솔루션. 바퀴를 재발명하는 대신 기성품 솔루션을 사용하는 데 소요되는 시간이 줄어듭니다. 일부 결정은 스스로 생각할 수 있지만 대부분은 스스로 발견한 것일 수 있습니다.
• 코드 표준화. 숨겨진 모든 문제가 오랫동안 발견되었기 때문에 일반적인 통합 솔루션을 사용하여 설계할 때 계산 착오를 덜 수 있습니다.
• 일반 프로그래밍 사전. 다른 프로그래머에게 당신이 생각해낸 멋진 디자인과 이를 위해 어떤 클래스가 필요한지 설명하는 데 한 시간을 소비하는 대신 패턴의 이름을 말합니다.

패턴은 무엇입니까?

패턴은 설계 중인 시스템의 복잡성, 세부 사항 및 적용 범위에 따라 다릅니다. 공사에 비유하자면 신호등을 설치해 교차로의 안전성을 높이거나 지하도를 설치해 전체 자동차 인터체인지로 대체할 수 있다.

가장 낮은 수준의 단순한 패턴은 관용구입니다. 하나의 프로그래밍 언어의 틀 내에서만 적용할 수 있기 때문에 보편적이지 않습니다.

가장 다재다능한 것은 거의 모든 언어로 구현할 수 있는 아키텍처 패턴입니다. 개별 요소가 아닌 전체 프로그램을 설계하는 데 필요합니다.

그러나 가장 중요한 것은 패턴의 목적이 다르다는 것입니다. 우리가 알게 될 패턴은 세 가지 주요 그룹으로 나눌 수 있습니다.

• 생성 패턴은 프로그램에 불필요한 종속성을 도입하지 않고 객체를 유연하게 생성합니다.
• 구조 패턴은 개체 간의 관계를 구축하는 다양한 방법을 보여줍니다.
• 행동 패턴은 개체 간의 효율적인 통신을 처리합니다.

1.4 UML 소개

Gang of Four 책에서 설명한 것과 동일한 23가지 패턴을 살펴보는 것으로 시작하겠습니다. 패턴 자체와 이름은 초보 프로그래머에게도 친숙합니다. 나는 그것들을 소개할 것이지만 패턴에 관한 바로 그 책을 읽는 것이 좋습니다.

디자인 패턴은 특정 프로그래밍 언어에 얽매이지 않으므로 일반적으로 UML을 사용하여 설명합니다. 20년 전에는 매우 인기가 있었지만 지금도 가끔 사용됩니다. 그리고 패턴에 대한 설명은 UML의 사용이 표준인 곳일 뿐입니다.

UML을 사용하면 서로 다른 엔터티 간의 관계를 설명할 수 있습니다. 우리의 경우 이들은 객체와 클래스입니다.

클래스 간의 관계는 네 가지 유형의 화살표로 설명됩니다.

	구성 (구성) - "부분"이 "전체"와 별도로 존재할 수 없는 집합의 아종.
	집계 - "부분" - "전체" 관계를 설명합니다. 여기서 "부분"은 "전체"와 별도로 존재할 수 있습니다. 마름모는 "전체" 쪽에서 표시됩니다.
	종속성 - 한 엔터티(독립)의 변경이 다른 엔터티(종속)의 상태 또는 동작에 영향을 줄 수 있습니다. 독립적인 개체는 화살표 측면에 표시됩니다.
	일반화 - 인터페이스의 상속 또는 구현 관계. 화살표 옆에는 수퍼클래스 또는 인터페이스가 있습니다.

사실 여기에서는 모든 것이 매우 간단합니다. 마지막 화살표는 실제로 한 클래스가 다른 클래스에서 상속되었음을 의미합니다. 첫 번째 및 두 번째 화살표는 한 개체가 두 번째 개체에 대한 링크를 저장한다는 것입니다. 그리고 그게 다야.

링크 다이아몬드가 검은색이면 링크가 약한 것입니다. 개체는 서로 없이 존재할 수 있습니다. HttpRequest다이아몬드가 흰색이면 개체는 class 및 해당 하위 class 와 같이 밀접하게 관련되어 있습니다 HttpRequest.Builder.

1.5 패턴 목록

패턴 유형은 다양한 색상과 문자로 표시됩니다.

비- 행동 (행동);

씨- 생성(창조);

에스- 구조적 (구조적).

마지막으로 23가지 디자인 패턴 목록입니다.