"디자인 패턴에 언어 기능이 없습니까?" [닫은]

프로그래머들이 여기 에서이 질문에 대한 답을 보았습니다 . 디자인 패턴과 OOP 관행에 대한 생각이 역동적이고 약한 유형의 언어에서 어떻게 변하는가? 거기에서 욕설이있는 기사 : 디자인 패턴에 언어 기능이없는 기사 링크가 있습니다. 그러나 내가 스 니펫을 발견 한 곳은 매우 흥미로워 보였고 그에 대한 인센티브가 있다면 경험에 대해 검증 될 수 있습니다.

PaulGraham은 "Peter Norvig는 디자인 패턴에서 23 개의 패턴 중 16 개가 Lisp에서 '보이지 않거나 단순'하다는 것을 발견했습니다."

또는 JavaScript로 클래스를 시뮬레이션하려는 사람들과 최근에 본 것을 확인하는 또 다른 문장 :

물론 "기능"패턴이나 "클래스"패턴 또는 대부분의 언어가 내장 기능으로 제공하기 때문에 당연한 것으로 여겨지는 수많은 것들에 대해 말하는 사람은 없습니다. OTOH, 순전히 프로토 타입 언어의 프로그래머? 프로토 타입으로 클래스를 시뮬레이션하는 것이 편리하다는 것을 알 수 있습니다 ...

또한 디자인 패턴이 의사 소통 도구라는 점 을 고려 하고 있습니다. 응용 프로그램 작성에 참여한 경험이 제한되어 있어도 소규모 PHP 팀이 중소형 인트라넷 응용 프로그램의 GoF 패턴을 배우도록 강요하는 등 비 패턴 ( 비효율적 및 / 또는 비생산적 전자)으로 볼 수 있습니다. 규모, 범위 및 목적이 효과적이고 생산적인 것을 결정할 수 있다는 것을 알고 있지만 여전히 그것에 대한 기술적 개요를 찾지 못했습니다.

나는 OOP와 기능이 혼합되어 유지 보수가 가능한 작은 상업용 응용 프로그램을 보았고, 많은 사람들이 파이썬에서 singleton을 작성하는 데 필요한지 모르겠지만 간단한 모듈도 같은 일을합니다.

따라서 디자인 패턴과 해결 방법, 간단한 방법 또는 언어 기능에 의한 대체를 고려한 연구, 철저한 기사 또는 다른 형태의 박람회가 있습니까?

programming-languages design-patterns

— 에두아르 플로리 네 스쿠
소스

Paul Graham이 프로그래밍 언어의 주제에 대해 "객관적이고 사실적"이라고 말한 것을 받아들이는 것은 실수 일 것입니다.

— 메이슨 휠러

나는 폴 그레이엄 (Paul Graham)과 동의하지 않는 경향이 있지만 @MasonWheeler는 옳습니다. 전도자들은 여러 가지 이유로 위대하지만 그들의 객관성은 아닙니다.

— 지미 호파

@JimmyHoffa : 일반적으로 "전도자"가 아닙니다. 나는 Graham의 오랜 자신의 출처와 자주 모순되는 내용을 게시하고 모든 것을 일관된 것처럼 보이게하려는 우스운 자료를 게시 한 것에 대해 문제를 제기합니다. 당신이 옹호하는 것이 무엇이든간에, 그것은 그것에 대해가는 끔찍한 방법이며, 사람들이 실제로 그 말을 듣는 것은 나에게 약간의 충격입니다.

— 메이슨 휠러

일부 연구를 살펴보면 좋을 것입니다. 그러나 현대적인 기능적 언어를 사용한 적이 있다면 이미 사용되지 않는 GOF 디자인 패턴을 알고 있으며 더 증명할 필요가 없습니다 . (그러나 그들은 1990 년에 중요했지만 의심 할 여지가 없습니다).

— c69

@DanielB, 현실은 모든 패러다임보다 훨씬 복잡하기 때문에 모든 특정 패러다임이 실패합니다. 따라서 모든 문제는 고유 한 도메인 별 모델과 패러다임이 필요합니다.

— SK-logic

나는 그 모든 것들을 고려한 심층 토론이나 연구를 알고 있지 않습니다 .

즉, "디자인 패턴은 OO 언어에서 누락 된 기능을 패치하는 것"이라는 모든 주장은 제 생각에는 약간 얇습니다. 예, 일부 디자인 패턴은 다른 언어 X에는 존재하지 않는 공통된 간격을 채우는 것과 정확히 일치합니다. 이들은 일반적으로 GoF 책의 일부 / 많은 원래 패턴과 같이 저수준의 단순한 디자인 패턴입니다.

그러나 디자인 패턴은 단순한 패턴보다 훨씬 뛰어나며, 누락 된 언어 기능을 호출하면 상상력이 확장됩니다. Fowler의 엔터프라이즈 애플리케이션 패턴 카탈로그를 살펴보고 언어의 핵심 정의의 일부인 경우 어떻게 될지 생각해보십시오. 엔터프라이즈 응용 프로그램 (그리고 매우 복잡한 언어 )에 대한 DSL (Domain-Specific Language ) 로 끝날 것입니다 .

실제로 이것은 디자인 패턴이 특정 문제 (일반적인 범용 언어로 적용되는)에 대해 재사용 가능한 솔루션을 만들어내는 방법입니다. "우리는 Active Records를 사용합니다"라고 말하면 다양한 접근 방식에 대해 몇 분씩 논의하지 않고도 애플리케이션에 대해 이미 많은 것을 알고 있습니다. 그렇습니다. 디자인 패턴은 언어 사양에서 패치 구멍을냅니다. 그들이하는 모든 일입니까? 아니-멀리서도 아닙니다.

편집하다:

어떤 방식으로, 내가 말하는 것은 OO 실무자들이 더 높은 수준으로 생각하고 그들의 언어에 대한 구문을 유지하면서 환경에 대한 DSL 유형을 거의 구성 할 수 있도록 패턴을 허용한다는 것입니다 . 그리고 네, 어디에서나 적용 할 때 어떤 일이 발생했는지 보았습니다 ( AbstractSingletonProxyFactoryBean , 그렇습니다, 존재합니다). 그들은 일종의은 총알이라고 생각합니다. 요점은 진정으로 편안해지기까지 오랜 시간이 걸리지 만 실제로는 높은 수준에서 예측 가능하고 이해할 수있게함으로써 복잡성을 낮추는 것입니다. 이것은 언어 장애에 대한 패치 키트와는 매우 다릅니다.

편집 2-패턴을 재미있게 만들기 위해 AbstractSingletonProxyFactoryBean 카운터 예제를 추가했습니다. AOP 라이트에서 볼 때 완벽하게 공평하게 말하면,이 반대의 예조차도 방어 할 수 있습니다.

— 다니엘 B
소스

DSL 및 응용 프로그램 패턴에 대한 검색 범위를 좁 혔기 때문에 (+1) 동의합니다. 매우 사려 깊으며 독자를 위해 확장하거나 링크 할 수 있습니까? DSL 약어 중 하나 이상이 도메인 특정 언어를 의미한다고 생각합니다.

— 에두아르 Florinescu

@EduardFlorinescu 덕분에 DSL 링크로 업데이트되었습니다.

— Daniel B

또한 그루비이 경우 답의 일부를 확인이 문서 발견 ibm.com/developerworks/java/library/j-eaed7/index.html

— 에드워드 Florinescu

@EduardFlorinescu 매우 흥미 롭습니다. 인터프리터 패턴을 구체적으로 언급 한 것은 아닙니다. 오히려 많은 패턴이 도메인에 따라 다를 수 있으며 해당 도메인의 개발자에게는 거의 관용적이되지 않습니다. 그런 의미에서, 그들은 일종의 DSL이되고, 이해하고 사용하기 위해 많은 노력을 기울이지 않습니다. 예를 들어 명령 패턴 (도메인이 아닌 특정 예)을 읽을 때 안전하게 무시할 수있는 상용구 코드를 알고 있으며 많은 노력을 기울이지 않습니다. 그럼에도 불구하고 흥미로운 링크에 감사드립니다.

— Daniel B