언어 구성에 디자인 패턴이 추가되지 않는 이유는 무엇입니까?

최근에 나는 그의 회사가 MVC 디자인 패턴을 PHP 확장으로 추가하고 있다고 언급 한 동료와 이야기를 나누었습니다.

그는 Controllers, Models and Views성능 향상을 위해 언어 구성 에 추가 하기 위해 C 코드를 작성했다고 설명했습니다 .

이제 MVC는 웹 응용 프로그램에서 널리 사용되는 아키텍처 디자인 패턴이라는 것을 알고 있지만 컨트롤러와 같은 언어 구성을 가진 언어를 사용해야합니다.

디자인 패턴을 언어로 통합하는 IMHO는 좋은 OO 디자인의 중요성을 강조 할 수 있습니다.

그렇다면 왜 가장 많이 사용되는 디자인 패턴 (MVC, 팩토리, 전략 등)이 언어 구성에 추가되지 않습니까?

질문이 너무 광범위하게 들리면 질문을 PHP로만 제한 할 수 있습니다.

편집하다:

나는 하나가 암시 아니에요 해야한다 프로젝트를 개발할 때 디자인 패턴을 사용합니다. 실제로 나는 그것이 작동하는 한 단순하게 유지하는 방법론을 장려합니다.

언어 패턴 에 디자인 패턴 이 항상 추가됩니다. 서브 루틴 호출 디자인 패턴에 대해 들어 보셨습니까 ? 아니? 나도 마찬가지야 그의 서브 루틴 호출 때문 이었다 거의 즉시 언어에 추가되었다 1950 년대 초에 디자인 패턴. 오늘날에는 CPU의 머신 코드 명령어 세트에도 있습니다.

무엇에 대한 For 루프 디자인 패턴? While 루프 디자인 패턴? 스위치 디자인 패턴? 객체 디자인 패턴? 클래스 디자인 패턴? 이 모든 언어가 일부 언어에 추가되었습니다.

그들 중 일부는 있습니다. 예를 들어 반복자는 많은 언어와 표준 라이브러리의 언어 기능입니다 (foreach 및 yield return). 관찰자는 이벤트 형태로 자주 존재합니다 (PHP는 아님-콜백 가입을 직접 관리해야 함). 명령은 WPF의 핵심 기능입니다.

다른 많은 사람들은 실제로 언어 지원의 이점을 얻지 못하고 언어를 더 번거롭게 만들 것입니다. 언어 기능을 디자인 할 수 있다면 컨트롤러를 어떻게 단순화 하시겠습니까? 클래스로서 클래스를 지원하기 위해 이미 존재하는 모든 인프라의 이점을 누릴 수 있습니다. 클래스를 인스턴스화하고 전달하고 다른 개체와 같이 단위 테스트와 같은 클래스 테스트를 수행 할 수 있습니다.

IMO가 일종의 언어 지원을 통해 얻을 수있는 유일한 MVC 구성 요소는 View (일부 공식 템플릿 엔진 사용)이며 PHP에서는 이미 지원됩니다-PHP 스크립트를 동적으로 생성하고로드 할 수 있습니다 ( 템플릿으로 사용되는 일종의 전처리).

팩토리 메소드에도 동일하게 적용됩니다. 원하는 언어 기능을 가질 수 있다면 어떻게 단순화 할 수 있습니까? 일부 언어 (예 : C ++)에없는 한 가지 기능은이 유형 이름에서 객체를 생성하는 기능이지만 대부분의 고급 언어는이를 수행 할 수 있습니다 (유용한 팩토리 메소드를 작성할 필요조차 없음). 그 외에는 인스턴스화하고 반환하고 객체화하는 메서드를 만들면됩니다.

일부 디자인 패턴은 실제로 언어 구조로 추가됩니다. 사람들은 일단 내장되면 "구문"으로 시작하기 때문에 식별되지 않습니다. Java의 예외 처리는 좋은 예입니다. 많은 사람들이 명시 적으로 비슷한 것을 코딩합니다. 핵심 구문의 일부가 아닌 경우 디자인 패턴으로.

그러나 질문에 집중하기 위해 언어에 너무 많은 디자인 패턴을 추가하지 않으려는 이유는 여러 가지가 있습니다.

• 언어 구성으로 추가 할 필요는 없습니다. 모든 디자인 패턴을 다른 방식으로 구현할 수 있습니다
• 언어를 복잡하게 만들 것입니다 -언어를 배우기가 어렵고 컴파일러와 도구를 작성하기가 더 어려워서 나쁜 생각입니다.
• 많은 디자인 패턴에 대한 대안적인 구현 접근법 이 존재합니다. 하나의 접근법을 선택하고 핵심 언어의 일부로 축복하면 사람들이 다른 방식보다 그 접근법을 사용하게 될 것입니다 (일부 상황에서는 훨씬 나을 수도 있음)
• 디자인 패턴에 대한 과도한 의존 은 어쨌든 나쁜 생각 일 것입니다. 언어 디자이너는 아마도 더 이상 격려하지 않아야한다는 것을 알고있을 것입니다.

당신은 메타 프로그래밍 기능을 충분히 강력한 언어 (예 : 리스프)를 사용하는 경우에도, 그것을 구현하는 언어를 직접 확장하는 비교적 간단하게 어떤 디자인 패턴을. 5 줄 매크로로 자신 만의 패턴을 쉽게 추가 할 수 있다면 핵심 언어에서 패턴이 전혀 필요하지 않습니다.

가장 많이 사용되는 디자인 패턴 (MVC, 팩토리, 전략 등)이 언어 구성에 추가되지 않는 이유는 무엇입니까?

이러한 패턴의 대부분은 특정 언어 지원없이 대부분의 프로그래밍 언어로 구현 될 수 있습니다. Java에서 MVC를 예로 들어 보겠습니다.

• 직접 코딩 할 수 있습니다.
• 응용 프로그램 생성기를 사용하여 구현할 수 있으며 동시에 많은 다른 상용구를 처리 할 수 ​​있습니다.
• "프레임 워크"라이브러리 클래스를 사용하여이를 구현할 수 있습니다.
• 주석 및 정적 또는 런타임 주석 처리를 사용하여이를 구현할 수 있습니다.

이러한 모든 옵션이 주어지면 언어를 직접 확장하는 데는 가치가 거의 없습니다. 그리고 많은 "단점"이 있습니다 :

• 그것은 초보자 문법의 삶을 어렵게 만드는 언어 구문을 어지럽히는 경향이 있습니다.
• 언어 사양을 더 크고 더 복잡하게 만들어서 언어 구현자가 더 어려워하는 경향이 있습니다. (물론 사양이 클수록 오류와 불일치가 발생할 가능성이 높습니다.)
• 언어 안정성과 관련된 문제 / 문제로 이어지는 또 다른 패턴을 추가해야하는 압력이 항상 존재합니다.
• 언어에서 특정 패턴 을 지원함으로써 패턴을 지원하는 특정 방법 을 고정 배선 할 수 있습니다.

그들은.

함수는 C에서 언어 구조가되기 전에 어셈블리 코드의 디자인 패턴이었습니다.

가상 함수는 C ++의 언어 구조가되기 전에 C의 디자인 패턴이었습니다.

그러나 트레이드 오프가 있습니다. 패턴에 상용구 코드 (두 개의 키워드조차 포함)가 포함 된 경우 이는 유용한 언어 기능임을 나타냅니다. 그러나 패턴이 단순하고 명확하다면 C의 "(int i = 0; i <10; i ++)"는 모든 사람이 같은 방식으로 작성하는 것이 여전히 유용하지만 "i = 0에서 10까지"보다 크게 길지 않으며 약간 다른 루프를 만들기 위해 그것을 변경하는 방법에 대한 명백한.

'4 인조'책을 읽으면 다음과 같이 분명해집니다.

1. 이 책의 디자인 패턴은 실제로 다른 OO 언어로 인코딩 된 잘 알려진 스몰 토크 규칙입니다.
2. 따라서 이러한 패턴을 OO 언어에 포함시킬 수 없습니다. 해당 언어 내에서 스몰 토크를 다시 구현할 것입니다. 스몰 토크를 직접 사용하는 것이 좋습니다
3. 디자인 패턴이 유용한 이유는 현재 사용되는 언어의 역할을 강조하지 않고 구문 이외의 다른 문제에 초점을 맞추기 때문입니다. 언어 내에서 이러한 패턴을 인코딩하면 디자인 패턴의이 기능이 손실됩니다.
4. 위의 질문에서 실제 문제는 소프트웨어를 작성하는 것이 언어를 배우는 것만이 아니라는 점을 놓친다는 것입니다. 언어가 직접 제공하는 언어와 충분한 거리를두고 현재 요구 사항에 집중하는 것이 중요합니다.

디자인 패턴은 사용자 코드로 완벽하게 구현되기 때문입니다. 그의 예제는 PHP이기 때문에 일어 났지만 실제로 성능이 필요한 경우 다른 언어로 작업하거나 HipHop 또는 다른 것을 얻을 수 있습니다.

언어 기능은 지정 및 구현이 복잡하므로 "현재 관용구는 X"라는 목적으로 만 언어를 만들 수는 없습니다. 의미있는 사용자 코드를 전혀 저장하지 않고 아무 것도 저장하지 않았습니다.

예, 부실한 질문이지만 승인 된 것을 포함하여 시맨틱 다이얼에서 "디자인 패턴"을 설정 한 위치에 따라 많은 답변에 동의하지 않습니다.

GoF 디자인 패턴 책의 의미에서, 나는 그것이 의존한다고 말합니다. 예를 들어 MVC (실제로는 GoF 패턴은 아니지만 금형에 적합)는 대량 소비를위한 언어 구성으로 표현하기에는 부적절합니다 (특정 PHP 프로젝트에는 적합 할 수 있음). 아키텍처 패턴으로서 테마에 대한 다양한 변형이 있으며 다양한 상황에서 테마에 대한 완벽하고 다양한 합법적 인 해석이 있습니다 (많은 사람들이 MVC에서 출발했지만 더 이상 MVC라고 부르지 않아야 함). 예를 들어, 웹에서 http 장벽은 클라이언트 측을 의심의 여지없이 방정식에 포함시키려는 지 여부와 더 많은 관점에서 "보기"를 고려하는 대상에 따라 다소 어색한 것으로 만듭니다. 적절하게 엄격하게 서버 측 관점.

반면, 반복자는 매우 다양한 개념으로 다양한 구성에 적용될 수있는 매우 일반적인 개념입니다.

서버 측 웹별 언어 인 IMO조차도 핵심 언어 설계에 속하는지 여부에 대한 선을 그려야하는 곳은 계산할 수없는 수의 일을 더 쉽게 수행 할 수있게하는 선을 넘어서는 지점입니다. 아키텍처 패턴과 같이 지나치게 구체적이지만 광범위하게 구현 된 작업을 수행하는 것이 더 쉽습니다.