4 인조는“패턴 공간”을 철저히 조사 했습니까?

144

적어도 10 년 전에 GoF (Gang of Four) 디자인 패턴 에 대해 처음 알게 된 이래로 ,이 23 개의 패턴은 패턴 공간 이라고 부르는 것보다 훨씬 큰 작은 샘플이어야한다는 인상을 받았습니다 . 이 가상의 패턴 공간 은 일반적인 객체 지향 소프트웨어 설계 문제에 대한 모든 권장 솔루션 (알거나 알 수 없음)으로 구성됩니다.

그래서 알려지고 문서화 된 디자인 패턴의 수가 크게 늘어날 것으로 예상했습니다.

일어나지 않았다. GoF 책이 나온 지 20 년이 지난 지금, Wikipedia 기사에는 12 가지 추가 패턴 만 나열되어 있으며, 그 중 대부분은 원본보다 훨씬 덜 유명합니다. (특정 주제를 다루기 때문에 동시성 패턴은 여기에 포함시키지 않았습니다.)

이유는 무엇입니까?

GoF 패턴 세트가 실제로 생각보다 포괄적입니까?
새로운 패턴을 찾는 데 관심이 없었습니까? 아마도 소프트웨어 디자인에 유용하지 않은 것으로 밝혀 졌을까요?
다른 것?

design-patterns object-oriented-design

— 프랭크 푸퍼
소스

49

패턴은 어디에나 있지만 맛이없고 로봇적인 방식으로 자주 사용됩니다. 이런 이유로, 패턴 카탈로그 아이디어는 덜 인기가 있다고 생각합니다.

— usr

6

디자인 공간? 마크 로즈 워터를 여기로 데려와, 스탯!

— corsiKa

16

Martin Fowler 는 2003 년에 약 50 가지 패턴을 기록한 Enterprise Application Architecture의 패턴을 게시했습니다.이 패턴 중 상당수는 오늘날에도 여전히 재구성 가능하고 잘 사용되고 있습니다.

— 브라이언 로저스

2

가능한 모든 패턴의 공간을 탐색하는 것은 가능한 패턴의 공간을 전혀 탐색하지 않는 것과 같습니다. 모든 것을 패턴으로 만들 수 있습니다. 모든 것을 패턴으로 만들면 단어가 의미를 잃기 때문에 아무것도 패턴이 아닙니다.

— 희망적으로도 도움이

4

@BradThomas : 물론 가장 흥미로운 질문처럼 사람들은 특정한 의견을 갖는 경향이 있습니다. 그러나 의견은 적어도 부분적으로 사실에 근거하고 있으며,이 질문에 대한 답변에서 다른 사람들이 자신의 의견을 다시 생각하고 더 확실한 의견을 제시하는 데 도움이되는 많은 흥미로운 사실을 발견했습니다.

— Frank Puffer

165

이 책이 나왔을 때 많은 사람들이 그렇게 생각했고 "패턴 라이브러리"또는 "패턴 커뮤니티"를 만들기위한 많은 노력이있었습니다. 여전히 일부를 찾을 수 있습니다.

"패턴 커뮤니티" , WikiWikiWeb
"뉴욕시의 디자인 패턴 연구 그룹" , 산업 논리
"패턴 카탈로그" , 힐 사이드 그룹

하지만...

소프트웨어 디자인에 그다지 유용하지 않기 때문에 새로운 패턴을 찾는 데 관심이 없었습니까?

아주 많이 요 디자인 패턴의 요점은 개발자 간의 의사 소통 을 향상시키는 것이지만, 더 많은 패턴을 추가하려고하면 사람들이 패턴을 기억하지 못하거나 잘못 기억하거나 정확히 어떻게 생겼는지에 대해 의견이 일치하지 않는 시점에 도달하게됩니다. 실제로는 개선되지 않았습니다. 이미 GoF 패턴에서 많은 일이 발생합니다.

개인적으로, 나는 더 나아갈 것입니다 : 소프트웨어 디자인, 특히 좋은 소프트웨어 디자인은 패턴으로 의미를 갖기에는 너무 다양합니다. 특히 사람들이 실제로 기억할 수있는 적은 수의 패턴에서 사람들은 생각하기에는 너무 추상적입니다. 정말 소수 이상의 것을 기억하십시오. 그래서 그들은별로 도움이되지 않습니다.

그리고 너무 많은 사람들이 개념에 매료되어 어디에서나 패턴을 적용하려고 시도합니다. 일반적으로 결과 코드에서는 모든 (완전히 의미가없는) 싱글 톤과 추상 팩토리 사이의 실제 디자인을 찾을 수 없습니다.

— 마이클 보그 워드
소스

50

논란의 여지가있는 의견 : 추상 공장은 어쨌든 코드 냄새입니다 :)

— MetaFight

66

논쟁의 여지가있는 의견 일 수도 있지만 표현하기에는 너무 중요한 의견 일 수도 있습니다. 디자인 패턴은 황제의 새로운 옷의 예가 될 위험에 처해 있습니다. 잘 했어.

— David Arno

18

@MetaFightControversialDesignPatternOnlineOpinionHumanReadableRetortFactory.newInstance().getText();

— corsiKa

11

" 디자인 패턴의 요점은 개발자 간의 의사 소통을 향상시키는 것입니다. "디자인 패턴은 개발자 가 일반적으로 (그리고 자주 독립적으로) 겪는 문제를 해결하는 것이라고 생각했습니다. 표준은 의사 소통을 개선하고 변동 (XY 문제로 인한 패턴, 반 패턴으로 간주되는 패턴)으로 인해 디자인 패턴을 표준으로 간주하지 않는 경우가 많습니다. 디자인 패턴은 언어 기능의 부족을 정확하게 지적하는 데 도움이되며 언어 디자이너가 디자인 패턴이되기 전에 이러한 문제 해결을 구현하고 있다고 생각합니다. 하지만 사실 내 말을 오해하지 마세요

— 빈스 Emigh에게

11

@ChrisW 나는 당신의 요점을 보지 못합니다 ... GoF가 OO 단점, 특히 C ++ 98 단점을 Smalltalk와 함께 선택한 언어이기 때문에 극복하려고 노력했습니다. 그들은 실제로 다음과 같이 썼다. "프로그래밍 언어의 선택은 관점에 영향을주기 때문에 중요하다. 우리의 패턴은 스몰 토크 / C ++ 수준의 언어 기능을 가정하고, 그 선택은 쉽게 구현할 수있는 것과 불가능한 것을 결정한다."

— Shautieh

108

이 23 개의 패턴은 패턴 공간이라고 부르는 것보다 훨씬 큰 샘플 일 뿐이라는 인상을 받았습니다.

이것은 신생 프로그래머, 어디서나 소프트웨어 패턴을 꿰매는 것만으로 프로그램을 작성할 수 있다고 생각하는 프로그래머들에 의해 전파되는 무서운 가정입니다. 그런 식으로 작동하지 않습니다. 이러한 "패턴 공간"이 있으면 크기가 사실상 무한하다고 가정 할 수 있습니다.

GoF 의미의 디자인 패턴 은 사용중인 프로그래밍 언어의 결함을 보완하는 데 한 가지 목적 이 있습니다.

디자인 패턴은 보편적이거나 포괄적이지 않습니다. 보다 표현력이 다른 프로그래밍 언어로 변경하면 GoF 책의 대부분의 패턴이 불필요하고 바람직하지 않게됩니다.

— 로버트 하비
소스

40

"GoF 의미의 디자인 패턴은 사용중인 프로그래밍 언어의 결함을 보완하는 데 한 가지 목적이 있습니다." 나는 이것을 계속 들었지만 아직 정당화되지는 않았다. 이것에 대한 모든 정당화는 일반적으로 방문자와 아마도 싱글 톤과 같은 일부 기능을 가진 언어로 구현하기 쉬운 소수의 패턴을 가리키고 있으며 대부분의 패턴은 그대로 유지하여 패턴을 중복 할 수 있음을 암시합니다. 더 나은 언어. 그러나 우리는 어떻게 알 수 있습니까? Observer와 관련없는 언어 기능은 무엇입니까? 책임의 사슬? 합성물?

— Jules

56

@Jules 퍼스트 클래스 함수만으로도 Chain of Responsibility (함수 목록의 구성에 불과 함)를 포함하여 상당한 부분이 제거됩니다. 기능적 반응성 프로그래밍은 관찰자 패턴을 제거합니다. 컴포지트 패턴은 모노 이드에 대해 덜 엄격하게 정의 된 정의이며, 유형 클래스 및 대 수법에 중점을 둔 언어는 모노 이드 작업을위한 강력한 도구를 제공합니다. 더 많이 나열 할 수는 있지만 아이디어를 얻을 수 있습니다.

— Jack

12

@ 줄스 : 원래 GoF 책에 반복자가 패턴으로 나열되어 있다고 생각하지만 언어 기능으로의 변환은 기본적으로 모든 원격 OOP 언어에서 완료됩니다.

— 케빈

9

@RubberDuck 패턴이 이미 구현되어 패턴을 더 이상 사용하지 않는 방법은 무엇입니까? 여전히 구현중인 디자인 패턴입니다. 다른 언어 기능 세트는 패턴의 다른 구현으로 이어질 수 있지만 패턴 자체는 여전히 존재합니다. 패턴은 일반적으로 사용되는 반복 전략에 이름을 부여하여 의사 소통을 용이하게합니다. 경우에 따라 .NET 클래스가 호출 ObservableSomething<T>되어 일반적으로 알려진 패턴 이름을 사용하므로 목적을 쉽게 이해할 수 있습니다. 패턴은 정확한 구현이 아니라 아이디어입니다.

— null

29

@ 줄 : 프로그램이란? 다시 발생하는 문제에 대한 해결책. 디자인 패턴이란 무엇입니까? 다시 발생하는 문제에 대한 해결책. 왜 프로그램이 아닙니까? 우리는 그것을 프로그램으로 표현할 수 없기 때문입니다. Ergo, 디자인 패턴은 언어가 프로그램을 표현할만큼 표현력이 충분하지 않기 때문에 디자인 패턴이 아니라 프로그램이어야하지만 프로그램이 될 수없는 재발 문제에 대한 솔루션입니다. 예 : 얼마 전부터 "서브 루틴 호출"은 디자인 패턴이었습니다! 요즘은 언어 기능입니다.

— Jörg W Mittag

61

여기에는 세 가지 요소가 있다고 생각합니다.

중요한 질량의 부족

첫째, 패턴은 기본적으로 특정 "청크"기능을 구현하는 일부 코드에 이름을 지정하는 것 이상입니다. 이름이 실제 가치를 제공하는 유일한 방법은 이름 을 사용하여 이름의 의미를 아는 모든 사람에게 의존 할 수 있다면 코드를 즉시 이해하는 것입니다.

패턴은 그것을 달성하는 데 필요한 임계 질량을 설정하지 않았습니다. 오히려 AAMOF와 반대입니다. GoF 책이 나온지 20 년이 지난 지금, 관련된 모든 사람들이 의사 소통을 향상시키기 위해 충분한 디자인 패턴을 알고있는 수십 개의 대화를 보지 못했을 것입니다.

좀 더 기묘하게 말하면 디자인 패턴은 실패했기 때문에 실패했습니다.

너무 많은 패턴

두 번째 주요 요소는 처음에는 너무 많은 패턴의 이름을 짓는 것입니다. 상당히 많은 경우에, 패턴들 사이의 차이는 미묘하여 특정 클래스가 하나의 패턴에 맞는지 (또는 어쩌면 둘 다 또는 아마도 둘 다) 실제로 확실하게 말할 수없는 것입니다.

의도는 코드에 대해 더 높은 수준으로 이야기 할 수 있다는 것입니다. 특정 패턴의 구현으로 상당히 큰 코드 덩어리에 레이블을 지정할 수 있습니다. 미리 정의 된 이름을 사용하기 만하면 듣는 모든 사람이 일반적으로 해당 코드에 관심이있는만큼 많은 정보를 알고 있으므로 다음 단계로 넘어갈 수 있습니다.

현실은 거의 반대되는 경향이 있습니다. 회의 중이라고 말하고이 특정 수업이 Facade라고 말하십시오. 회의에 참석 한 사람들의 절반은 그 의미를 정확히 잊었거나 오랫동안 잊어 버린 적이 있습니다. 그들 중 하나는 파사드와 프록시 사이의 정확한 차이점을 상기시켜달라고 요청합니다. 아, 그리고 패턴을 실제로 아는 두 사람은 회의의 나머지 부분에서 이것이 실제로 Façade로 간주되어야하는지 아니면 "어댑터"로 간주되어야하는지에 대해 토론합니다.

"이 코드는별로 흥미롭지 않고 계속 진행해 보자"라는 의도만으로 가치가 아니라 패턴 만 추가 된 산만 함을 사용하려고합니다.

관심 부족

대부분의 디자인 패턴은 실제로 흥미로운 코드 부분을 다루지 않습니다. 그들은 "어떻게이 오브젝트를 작성합니까?", "어떻게이 오브젝트가 그 오브젝트와 대화하도록합니까?"와 같은 것을 처리합니다. 이것에 대한 패턴 이름을 기억하는 것은 (세부 사항에 대한 전술 한 주장뿐만 아니라) 대부분의 프로그래머가 신경 쓰지 않는 것에 많은 에너지를 넣는 것입니다.

약간 다르게 말하자면 패턴은 많은 프로그램들 사이에서 동일한 것을 처리하지만 실제로 프로그램을 흥미롭게 만드는 것은 다른 프로그램 과 어떻게 다른가 입니다.

요약

다음과 같은 이유로 디자인 패턴이 실패했습니다.

그들은 임계 질량을 달성하지 못했습니다.
명확성을 보장하기 위해 패턴 간의 구별이 불충분했습니다.
그들은 어쨌든 거의 아무도 신경 쓰지 않은 코드 부분을 처리했습니다.

— 제리 관
소스

2

"...하지만 실제로 프로그램을 흥미롭게 만드는 것은 다른 프로그램과 다른 점입니다." 나는 완전히 동의하지만, 당신은 먼저 같은 부분을 올바르게 잡아야한다는 점에 대해, 아마도 사소한 측면에 따라 다를 수 있습니다. 패턴의 이름을 지정하고 식별해야 할 필요성을 조금이라도 완화 시키면 거의 모든 패턴을 볼 수 있다고 확신합니다. 단지 그들이 순수한 형태로 오지는 않지만 항상 당면한 문제에 어느 정도 적응한다는 것입니다.

— Trilarion

5

아주 좋은 대답입니다.

— Robert Harvey

4

@ Trilarion : 아, 코드의 해당 부분을 작성해야한다는 것을 알고 있습니다. 예를 들어 차의 타이어와 비슷합니다. 운전할 때는 타이어가 거의 필요하지만 대부분의 사람들은 여전히 자동차의 타이어 브랜드를 거의 알지 못합니다. 이것은 비대칭 대각선 그루브가있는 타이어에 대한 특별한 용어를 배우도록 요구합니다. 누가 알겠는가-그들은 내 인생을 한 번 구했을 수도 있지만, 나는 아직도 그들의 인생을 위해 그들의 이름을 배우는 데 소비하지 않습니다.

— Jerry Coffin

3

@DavidRicherby : 자, 그럼 "생산자 쪽"버전의 비유를 사용합시다. Goodyear를 위해 타이어를 디자인 한 John이 해당 유형의 홈에 대해 한 단어를 사용하지만 Michelin에서 일하는 Pierre는 완전히 다른 단어를 사용하는 것이 중요합니까? 하나는 그루브만을 가리키는 단어를 사용하지만 다른 하나는 중앙의 한쪽에는 수평 그루브가 있고 다른 하나는 대각선 그루브가있는 완전한 타이어를 말하는 것이 중요합니까?

— Jerry Coffin

2

@immibis : 나는 대부분 그렇다고 말했을 것입니다. 대부분의 프로그래머가 인식하는 패턴은 6 십 개 미만입니다. 싱글 톤은 잘 알려져 있지만 실제로는 거의 적용 할 수 없습니다 (최상의). 이름은 "공장"긴 "패턴"(나는 1970 년대 또는 후반에서의 사용 기억을 따라 오기 전에 일반적으로 사용했다 매우 1980 년대 초반을). 패턴은 어휘를 구성해야했지만 현재 그리스어로 된 내 어휘와 비슷합니다. (아마도) 곤경에 처할 수는 있지만, 메뉴를 주문하기에는 충분하지 않으며, 의미있는 대화는 훨씬 적습니다.

— Jerry Coffin

35

패턴에 추상화가 누락되고 간단한 패턴이 추상화되고 복잡한 패턴이 인식되지 않으므로 패턴이 유용하지 않습니다 (일부 상위 레벨 제외).

Paul Graham이 가장 잘 말했다고 생각합니다.

프로그램에서 패턴을 볼 때 문제의 징후라고 생각합니다. 프로그램의 형태는 해결해야 할 문제 만 반영해야합니다. 코드의 다른 규칙은 적어도 나에게는 충분히 강력하지 않은 추상화를 사용하고 있다는 표시입니다. 종종 필자가 직접 작성해야 할 매크로의 확장을 수동으로 생성한다는 것입니다.

코드에서 패턴을 인식하면 무언가 반복되는 것을 의미하므로 더 나은 추상화를 사용해야합니다. 더 나은 추상화가 없으면 패턴을 임시 해결책으로 사용하십시오. 새로운 프로그래밍 언어는 더 나은 추상화를 제공하기 때문에 패턴의 유용성이 떨어집니다.
또한 간단한 패턴은 종종 쉽게 추상화되고 복잡한 패턴은 거의 인식되지 않습니다.
패턴이 추상화로 대체 될 때, 패턴 뒤에있는 개념이 사라지는 것이 아니라 개념을 간접적으로 대신 명시 적으로 작성할 수 있으며 다른 코드에 비해 더 이상 특별하지 않으며 더 이상 다음과 같이 인식 할 수 없게됩니다. 패턴.

— 사이퍼
소스

2

개인적으로, 나는이 아이디어를 어떻게 든 정말로 좋아합니다. 그러나 패턴은 사람과 사람이 읽을 수 있어야합니다. 패턴은 길을 찾는 데 도움이됩니다. 코드에서 모든 패턴을 제거 하면 읽을 수 없게됩니다.

— Frank Puffer

2

@Frank 저는 PG가 어디에서 왔는지 생각합니다. 패턴은 추상화 할 수있는 기본 함수의 '냄새'이며, 함수 나 매크로로 패턴을 꺼내지 않았다는 사실이 반복의 원인입니다. 당신이하지 않은 경우 String.replace기능을, 당신은 패턴으로 팝업하지만, 더 잘 쓰기 한 번보다는 다시 구현 계속 상상할 수있다. 이러한 이름을 올바르게 지정하지 않으면 읽기가 더 어려워 지지만 올바르게 완료되면 코드가보다 선언적으로 IMO를 읽습니다 (예 : getOrElse옵션 모나드 대 null 검사 스타일)

— anotherdave

11

Paul Graham은 GoF "패턴"아이디어와는 다른 솔루션을 DRY로 유지하는 것에 대해 인용했습니다. GoF 아이디어는 일반적으로 사용되는 솔루션에 이름을 부여하는 것이 었습니다. 우리는 GoF가 그들의 책을 출판하기 오래 전에 이미 그 일을하고있었습니다. 예를 들어, 동료에게 대기열 을 사용하겠다고 알릴 수 있으며 동료는 대기열의 기능 또는 작동 방식에 대한 세부 정보를 설명 할 필요없이 내가 말하는 내용을 즉시 알 수 있습니다. 그러나 위의 Michael Borgwardt의 훌륭한 답변을 참조하십시오.

— 솔로몬 천천히

10

내 의견으로는,이 답변은 패턴이 무엇인지 오해합니다. 디자인 패턴은 흔히 발생하는 문제에 대한 해결책입니다. 코드 중복이 아닙니다. 반복자를 가져 가라. 컨테이너를 추상화하는 문제를 해결하여 컨테이너가 무엇이든 관계없이 컨테이너 내부의 요소를 살펴볼 수 있습니다. 따라서 각 컨테이너에 대해 반복자 클래스를 작성하고 공통 인터페이스를 구현하는 반복자 클래스를 작성하십시오. 여기서 추상화해야 할 것은 무엇입니까? 반복자는 이미 추상화입니다. 물론 모든 컨테이너에 대해 다르게 구현되므로 코드 복제가 없습니다.

— Malcolm

3

Graham의 인용문의 핵심 부분은 필자가 직접 작성해야 할 매크로의 확장을 수동으로 생성한다는 것입니다. 이것은 구체적으로 Lisp 매크로를 참조합니다. 매크로없이 할 수있는 추상화는 너무 많습니다.

— Bart van Nierop

13

나는 다른 사람들이 여기에 대답 한 것에 주로 동의하지만, 개인적으로 패턴의 수가 증가하지 않는 주된 이유는 무수한 패턴이있을 때 패턴의 의미가 느슨해지기 때문이라고 생각합니다. 이러한 몇 가지 패턴의 좋은 점은 표준 방식으로 많은 문제 영역을 다루는 것입니다. 끝없는 패턴 도메인에 집중한다면 패턴이 전혀 없게됩니다. "아일랜드의 해안선은 얼마입니까?"와 비슷합니다. 지도에서 측정하면 괜찮은 숫자가 제공됩니다. 그러나 더 정확하고 더 정밀한 해상도를 얻으려고하면 길이가 점점 더 무한대 (또는 불확실성)로 증가한다는 것을 알게 될 것입니다. 조수와 원자 수준에서 정확한 경계를 어떻게 측정할까요?

— qwerty_so
소스

1

패턴이 너무 많지 않은 경우에만 패턴이 작동합니다. 그러나 왜 GoF가 여전히 가장 인기 있는가? 그들 중 일부는 현재 많은 사람들 (Singleton, Builder 등)에 의해 반 패턴으로 간주됩니다. 이것은 총 수를 늘리지 않고 새롭고 더 유용한 패턴을위한 공간을 만들어야합니다.

— Frank Puffer

2

나는 그것이 십계명과 같다고 생각합니다. 출처는 단 2 글자 (GOF, GOE, GOD) xD

— qwerty_so

9

예. 중세 과학 학자들이 아리스토텔레스와 관련된 것처럼 현대 소프트웨어 공학이 GoF와 관련이있는 것 같습니다.

— Frank Puffer

11

다른 답변 중 언급되지 않은 내용도 관련이 있습니다.

동적 형식 언어의 등장.

이 책이 처음 나왔을 때 자바가 너무 느려서 실제 작업을하기에는 너무 진지한 토론이있었습니다. 이제 자바는 속도 때문에 표현 언어보다 자주 사용됩니다 . 어쩌면 Ruby, Python, JavaScript 등은 여전히 중요한 응용 프로그램 클래스에 비해 너무 느리지 만 대체로 대부분의 경우 충분히 빠릅니다. 그리고 모든 릴리스에 더 많은 기능이 포함되어 있어도 JavaScript는 실제로 더 빨라지고 있습니다.

원본 GoF 서적은 smalltalk와 c ++ 모두에서 패턴을 가지고 있으며 메모리가 제공되는 경우 smalltalk에서 패턴이 항상 더 짧았고 때로는 크게 감소했습니다. 클래식 디자인 패턴의 일부 기능은 실제로 정적 유형 시스템에 동적 기능을 추가하는 방법입니다 (이미 논의 된 AbstractFactory와 같이 런타임 데이터를 기반으로 올바른 클래스를 인스턴스화 함). 다른 언어는 동적 언어가 너무 짧아서 언어 자체를 관용적으로 사용하기 쉽습니다.

— 자레드 스미스
소스

10

그것은 않았다 일어난다. 출판사와 저자가 또 다른 악대를 뛰어 넘 으려고 시도하면서 컴퓨터 과학 전체를 디자인 패턴으로 축소하려는 시도로 수백 권의 책이 출판되지는 않았지만 수십 권의 책이 출판되었습니다. 나는 그들에게 선반이 있습니다. 처음 스캔 한 이후에는 상담하지 않았으며, 실제로 사용하지 않았거나 이미 잘 알려지지 않았기 때문에 빨랐습니다. 한 단락 대신 12 페이지)), 패턴이 적을수록 좋을수록 좋습니다. 실제로 Type Object에 대한 반박을 게시했을 때 텍스트 를 디자인 패턴으로 다시 캐스팅하라는 지시를 받았습니다 .실화. 또한 프로젝트의 또 다른 결함을 보여줍니다 : 검토 또는 배제 또는 거부 메커니즘.

실제로 GoF는 실제로 '디자인 패턴을 철저히 탐색'하려고 시도하지 않았습니다. 오히려 그들은 훨씬 더 큰 프로젝트에 참여했다. 기괴한 표현력, 참가자 등의 기괴한 아르카나와 함께 CS에 '패턴 언어'를 도입하는 것은 근본적으로 오해가 있었으며 무의미했기 때문에 단순히 실패했다.

그들이 성취 한 것은 유용 했고 두 가지 일이었습니다.

방문자 패턴과 같은 몇 가지 유용한 트릭을 게시
Factory, Adapter, Iterator 등의 표준 이름 세트를 제공하십시오. 바로 사전에 설계된 CORBA를 살펴보면 다음과 같은 가치가 있습니다. 인터셉터와 같은 모든 종류의 '외국'이름 , 하인, 중개인, ...

발생 된 또 다른 유용한 개념은 '반 패턴'(예 : 'log and throw')이었습니다. CS의 많은 유행과 마찬가지로이 프로젝트는 자신의 전도와 또 다른 CS 종교로 잘못 채택되어 탈선되었으며 대부분의 종교의 길을 갔다. 부분적으로 유용하지만 확실히 '은탄은 없다'((c ) Fred Brooks, 1965). 우리는 몇 년마다 그것을 재발견해야한다는 것이 슬픈 일입니다.

— 사용자 207421
소스

— 그것이이

1

@ r3wt 비보안. 내가 슬프게 한 것은 모든 새로운 개발이 신화적인 은총 알이 될 것이라는 생각에 대한 IT 산업의 약점이며 우연히 자체 작업의 일부를 버리고 있다는 것입니다.

— user207421

2

다른 관점에서 봅니다. 답을 읽고 실수를 반복하지 않는 법을 배우는 것이 슬프지 않습니다. 당연하다고 생각하는 것은 실제로 다른 사람들에게 매우 유용합니다.

— r3wt

6

/ 여러 권의 책이 풍덩 (이 제목이되어 있었다 패턴 프로그램 디자인의 언어 에서 발표 된 논문의 각 선집이다) 연례 회의 .

책을 읽었을 때, 패턴 중 일부는 흥미롭고 새롭고 일부는 표준입니다 (예 : "반 물체 + 프로토콜").

따라서 GoF의 컬렉션은 완전하지 않았으며 사람들이 새로운 것을 수집 / 설명 / 발견 / 발명하도록 영감을주었습니다.

"Wikipedia 기사에 나열된 12 가지 추가 패턴"은 아마도 완전한 모음이 아닐 것이다.

— ChrisW
소스

예, 수백 개의 패턴을 검색하면 설명을 찾을 수 있습니다. 그러나 이것들 중 어느 것도 GoF만큼 인기있는 것 같지 않습니다.

— Frank Puffer

GoF 책을 읽는 것을 좋아했기 때문에 책을 출판 할 때 더 많은 책을 읽었습니다 (나중에).

— ChrisW

1

@FrankPuffer 이름이 아닌 경우에도 패턴이 인기가있을 것입니다.

— dcorking

5

GoF (Gang of Four) 서적에는 기능이없는 언어로 숙련 된 프로그래머가 툴 벨트에 가지고있는 대부분의 패턴이 포함되어 있습니다. 모든 빌더가 사용 방법을 알고있는 기본 도구 세트와 같습니다. 이 책의 주요 공헌은 당시 대부분의 숙련 된 프로그래머가 공통적으로 사용했던 패턴의 이름을 잘 정의하여 디자인 옵션을 논의하는 프로그래머 간의 의사 소통을 돕는 것입니다.

전기 기술자에게는 일반 빌더가 제공하지 않는 일부 도구가있을 것으로 예상됩니다. 마찬가지로 WPF 프로그래머가 "종속성 속성"의 디자인 패턴을 알고 있거나 "SQL 프로그래머"가 트리거를 사용하여 감사 데이터를 작성하십시오.

그러나 이러한 기술은 하나의 기술에서만 사용되므로 "디자인 패턴"으로 생각하지 않습니다.

패턴 책은 좀 더 모뎀 디자인은 "리팩토링은, 기존 코드 (마틴 파울러)의 디자인 향상" 및 "클린 코드 : 애자일 소프트웨어 장인의 핸드북 (로버트 C. 마틴) " 이 책은 모두 당신이 만드는 변환으로 내용을 제시 "사전 준비된 재사용 가능한 디자인"이 아니라 현재 코드에 적용되지만 "디자인 패턴"만큼이나 중요합니다.

— 이안
소스

3

다음은 Erich Gamma와의 인터뷰에서 그가 선택한 패턴과 오늘 변경 한 사항을 반영한 것입니다 (오늘 10 년 전 현재 하하).

http://www.informit.com/articles/article.aspx?p=1404056

래리 : "디자인 패턴"을 어떻게 리팩토링 하시겠습니까?

에리히 : 우리는 2005 년에이 운동을했습니다. 우리는 객체 지향 디자인 원칙과 대부분의 패턴이 그 이후로 변하지 않았 음을 발견했습니다. 분류를 변경하고 새로운 멤버를 추가하고 일부 패턴을 삭제하고 싶었습니다. 대부분의 토론은 분류를 변경하는 것과 특히 어떤 패턴을 떨어 뜨릴 것인지에 관한 것입니다.

어떤 패턴을 떨어 뜨릴지를 논의 할 때 우리는 여전히 모든 패턴을 좋아한다는 것을 알았습니다. (실제로는 — 단독을 떨어 뜨리는 것을 선호합니다. 거의 항상 디자인 냄새가납니다.)

다음은 몇 가지 변경 사항입니다.

통역사와 Flyweight는 실제로 다른 패턴과는 다른 짐승이기 때문에 "기타 / 화합물"이라고하는 별도의 범주로 이동해야합니다. 팩토리 메소드는 팩토리로 일반화됩니다.

범주는 핵심, 창조, 주변 및 기타입니다. 여기서 의도는 중요한 패턴을 강조하고 덜 자주 사용되지 않는 패턴과 분리하는 것입니다.

새로운 멤버는 Null 개체, 형식 개체, 종속성 주입 및 확장 개체 / 인터페이스입니다 (프로그램 디자인 3의 패턴 언어, Addison-Wesley, 1997의 "확장 개체"참조).

이들은 카테고리입니다 :

핵심 : 복합, 전략, 상태, 명령, 반복자, 프록시, 템플릿 방법, 외관

창작 : 팩토리, 프로토 타입, 빌더, 종속성 주입

주변 장치 : 추상 팩토리, 방문자, 데코레이터, 중재자, 유형 객체, Null 객체, 확장 객체

기타 : 플라이급, 통역사

— 아쿤
소스

왜 당신은 저를 downvoting입니까? 답변을 향상시킬 수 있도록 의견을 설명하십시오.

— akuhn

3

이 책의 실제 패턴은 때로는 실제로 유용하지만 실제로는 그 책에서 제공하는 더 강력한 도구의 예일뿐입니다. 인터페이스에 의해 분리되고 규제되는 독립적 인 부분에서 모 놀리 식 코드를 자르는 것이 더 나은시기와 위치에 대한 깊은 이해 .

이 기술을 배우면 모든 단일 패턴의 정확한 세부 사항을 기억할 필요가 없다는 것을 알고 있습니다. 구현하려는 솔루션을 목적에 가장 적합한 방식으로 항상자를 수 있기 때문입니다. 따라서 점점 더 많은 패턴을 작성한다는 아이디어는 매우 학문적이고 무의미 해 보입니다.

— lud1977
소스

그러나 좋은 점은 많은 사람들이 그 책 (또는 일반적인 패턴)을 그런 식으로 이해한다는 것입니다.

— Frank Puffer

@ lud1977 우리가 역사를 기록하지 않으면 미래가 같은 함정에 빠지지 않는 이유는 무엇입니까? 따라서 항상 기록해야합니다. 무의미하지 않습니다.

— r3wt

2

그래서 알려지고 문서화 된 디자인 패턴의 수가 크게 늘어날 것으로 예상했습니다.

일어나지 않았다. GoF 책이 나온 지 20 년이 지난 지금, Wikipedia 기사에는 12 가지 추가 패턴 만 나열되어 있으며, 그 중 대부분은 원본보다 훨씬 덜 유명합니다. (특정 주제를 다루기 때문에 동시성 패턴은 여기에 포함시키지 않았습니다.)

GoF 서적과 위키 백과는 알려진 디자인 패턴의 유일한 소스는 아닙니다. Amazon.com에서 "디자인 패턴"만 검색하면 수백 권의 책을 얻을 수 있습니다 (이 검색을 시도하십시오 ). 나는 그들이 Wikipedia 기사 에서 가장 잘 알려진 패턴만을 나열한 것 같다 .

문제는 문서화 된 디자인 패턴이 충분하지 않다는 것입니다. 그 누구도 그들 모두를 기억할 수없는 것이 많으며 대부분의 프로그래머는 소수만 인식합니다. 이 시점에서 공통 패턴 언어의 큰 가능성이 무너집니다.

— 일루와 타
소스

-1

아직 생각하지 못한 많은 구조가있을 것입니다. 사람들이 소프트웨어를 개발하는 한 극복해야 할 디자인 문제가 있습니다. 이들 중 일부는 다른 사람들이 사용할 수있는 영리한 새 패턴을 사용하여 해결할 수도 있습니다.

프로그래밍 언어는 가장 일반적으로 사용되는 패턴을 추출하기 위해 개발 및 진행되었습니다. 이러한 패턴은 여전히 언어 디자인에 존재합니다. 따라서 오늘날 무시 될 수 있지만 그렇게 중요하지는 않습니다.

집을 지을 수있는 로봇이 있다면 집을 짓는 방법에 대한 지식이 갑자기 중요하지 않습니까? 나는 아니라고 주장한다. 수요가 급격히 떨어지고 아무도 그것을 연구하지 않기 때문에 연구에 대한 관련성이 적고 확실하며 아마도 보상이 훨씬 적습니다.

그래서, 패턴 공간이 소진되었다고 믿지 않습니다. 또 다른 대답이 지적했듯이 무한한 것 같습니다. 그러나 시스템 설계에 대한 요구가 감소함에 따라 추상화 타워의 높이와 프로그래밍 언어의 힘이 높아짐에 따라 최상위 계층에 점점 더 적은 사람들이 타워가 어떻게 구축되었는지에 대한 세부 사항에주의를 기울일 것입니다. .

— 팀
소스

-2

패턴은 무한합니다. 각 패턴을 조정하거나 n 개의 패턴을 혼합하여 새로운 패턴을 만들 수 있습니다. 엔터프라이즈 통합 패턴도 잘 정의되어 있습니다. 따라서 gof는 uml을 사용하여 패턴을 문서화하는 데 어려움을 겪고이를 설명하기위한 표준을 만들었습니다. 각 도메인 패턴마다 진화하고 파이썬이나 스칼라와 같은 표현 언어에 따라 변경됩니다.

— 마루 트 싱
소스