기능 프로그래밍이 GoF 디자인 패턴을 대체합니까?

작년에 F # 과 OCaml을 배우기 시작한 이후 , 디자인 패턴 (특히 Java)이 명령형 언어에서 누락 된 기능에 대한 해결책이라고 주장하는 수많은 기사를 읽었습니다. 내가 찾은 한 기사 는 상당히 강력한 주장을합니다 .

내가 만난 대부분의 사람들 은 Gang of Four (GoF) 의 Design Patterns 책 을 읽었습니다 . 자존심있는 프로그래머라면 누구나이 책이 언어에 구애받지 않고 사용하는 언어에 관계없이 소프트웨어 엔지니어링에 일반적으로 적용되는 패턴을 알 수 있습니다. 이것은 고귀한 주장입니다. 불행히도 그것은 진실에서 멀리 떨어져 있습니다.

기능적 언어는 매우 표현력이 뛰어납니다. 기능적 언어에서는 언어가 너무 높기 때문에 디자인 패턴이 필요하지 않으므로 디자인 패턴을 모두 제거하는 개념으로 프로그래밍해야합니다.

FP (Functional Programming)의 주요 기능에는 1 급 값, 카레, 불변 값 등의 기능이 포함됩니다. OO 디자인 패턴이 이러한 기능 중 하나에 가깝다는 것은 분명하지 않습니다.

또한 OOP를 지원하는 기능 언어 (예 : F # 및 OCaml)에서는 이러한 언어를 사용하는 프로그래머가 다른 모든 OOP 언어에서 사용할 수있는 것과 동일한 디자인 패턴을 사용한다는 것이 분명해 보입니다. 실제로 지금은 매일 F #과 OCaml을 사용하고 있으며, 이러한 언어에서 사용하는 패턴과 Java로 작성할 때 사용하는 패턴간에 뚜렷한 차이가 없습니다.

함수형 프로그래밍이 OOP 디자인 패턴이 필요 없다는 주장에 대한 진실이 있습니까? 그렇다면 전형적인 OOP 디자인 패턴과 그에 상응하는 기능의 예를 게시하거나 연결할 수 있습니까?

인용 한 블로그 게시물의 소유권 주장이 약간 과장되었습니다. FP는하지 않습니다 제거 디자인 패턴에 대한 필요성을. "디자인 패턴"이라는 용어는 FP 언어에서 동일한 것을 설명하는 데 널리 사용되지 않습니다. 그러나 그들은 존재합니다. 함수형 언어는 "문제 X가 발생하면 Y처럼 보이는 코드 사용"과 같은 모범 사례 규칙을 많이 가지고 있으며 이는 기본적으로 디자인 패턴입니다.

그러나 대부분의 OOP 특정 디자인 패턴은 기능적 언어와 관련이없는 것이 맞습니다.

나는 디자인 패턴 이 일반적으로 언어의 단점을 보완하기 위해 존재 한다고 말하는 것이 논쟁의 여지가 없다고 생각합니다 . 그리고 다른 언어가 같은 문제를 사소하게 해결할 수 있다면 다른 언어에는 디자인 패턴이 필요하지 않습니다. 해당 언어의 사용자는 해당 언어의 문제 가 아니기 때문에 문제 가 있음을 인식하지 못할 수도 있습니다 .

다음은 Gang of Four가이 문제에 대해 말한 내용입니다.

프로그래밍 언어의 선택은 자신의 관점에 영향을주기 때문에 중요합니다. 우리의 패턴은 스몰 토크 / C ++ 레벨 언어 기능을 가정하며, 그 선택에 따라 쉽게 구현할 수있는 것과 불가능한 것이 결정됩니다. 절차 언어를 가정하면 "상속", "봉지"및 "다형성"이라는 디자인 패턴을 포함했을 수 있습니다. 마찬가지로 일부 패턴은 덜 일반적인 객체 지향 언어에 의해 직접 지원됩니다. 예를 들어, CLOS에는 방문자와 같은 패턴의 필요성이 줄어드는 다중 방법이 있습니다. 실제로 스몰 토크와 C ++ 사이에는 충분한 차이가있어 어떤 패턴은 다른 언어보다 한 언어로 더 쉽게 표현 될 수 있습니다. (예를 들어 반복자 참조)

(위는 4 페이지 3 항 디자인 패턴 소개 책에서 인용 한 것입니다)

함수형 프로그래밍의 주요 기능에는 일류 값, 카레, 불변 값 등의 함수가 포함됩니다. OO 디자인 패턴이 이러한 기능 중 하나에 가깝다는 것은 분명하지 않습니다.

일류 함수의 근사치가 아닌 경우 명령 패턴은 무엇입니까? :) FP 언어에서는 단순히 함수를 다른 함수의 인수로 전달합니다. OOP 언어에서는 클래스에서 함수를 마무리해야합니다. 클래스에서 인스턴스화 한 다음 해당 함수를 다른 함수로 전달할 수 있습니다. 효과는 동일하지만 OOP에서는 디자인 패턴이라고하며 훨씬 더 많은 코드가 필요합니다. 카레하지 않으면 추상 팩토리 패턴은 무엇입니까? 한 번에 조금씩 매개 변수를 함수에 전달하여 마지막으로 호출 할 때 어떤 종류의 값을 내뿜는 지 구성하십시오.

따라서 더 강력하고 사용하기 쉬운 대안이 있기 때문에 여러 GoF 디자인 패턴이 FP 언어로 중복 렌더링됩니다.

그러나 FP 언어로 해결 되지 않은 디자인 패턴이 여전히 있습니다. FP는 싱글 톤과 동일합니까? (단일 톤은 일반적으로 사용하기에 끔찍한 패턴이라는 점을 무시하십시오.)

그리고 그것은 두 가지 방식으로 작동합니다. 내가 말했듯이 FP에는 디자인 패턴도 있습니다. 사람들은 보통 그것들을 그렇게 생각하지 않습니다.

그러나 모나드를 가로 질러 갔을 수도 있습니다. "글로벌 상태를 다루는"디자인 패턴이 아니라면 무엇입니까? 이는 OOP 언어에서 매우 단순한 문제이므로 동등한 디자인 패턴이 존재하지 않습니다.

당신이 단지 무엇 때문에, "그 소켓에서 읽기" "정적 변수를 증가", 또는 위해 우리는 디자인 패턴이 필요하지 않습니다 할 .

모나드를 디자인 패턴이라고 말하는 것은 일반적인 연산을 수행하는 정수를 말하는 것과 같이 터무니없고 제로 요소는 디자인 패턴입니다. 아닙니다. 모나드는 디자인 패턴이 아닌 수학적 패턴 입니다.

(순수한) 기능적 언어에서는 모나드 "디자인 패턴"또는 동일한 것을 허용하는 다른 방법으로 문제를 해결하지 않으면 부작용과 변경 가능한 상태가 불가능합니다.

또한 OOP를 지원하는 기능 언어 (예 : F # 및 OCaml)에서는 이러한 언어를 사용하는 프로그래머가 다른 모든 OOP 언어에서 사용할 수있는 것과 동일한 디자인 패턴을 사용한다는 것이 분명해 보입니다. 실제로 지금은 매일 F #과 OCaml을 사용하고 있으며,이 언어에서 사용하는 패턴과 Java로 작성할 때 사용하는 패턴간에 뚜렷한 차이가 없습니다.

아마도 당신은 여전히 ​​필수적으로 생각하기 때문에? 많은 사람들이 평생 명령형 언어를 다룬 후에는 기능적 언어를 시도 할 때 그 습관을 포기하는 데 어려움을 겪습니다. (F #에서 문자 그대로 모든 함수는 기본적으로 C 프로그램을 사용하는 것처럼 문자열로 'let'문의 문자열이었고 모든 세미콜론을 'let'으로 바꿨습니다.)

그러나 또 다른 가능성은 OOP 언어의 디자인 패턴이 필요한 사소한 문제를 해결하고 있다는 사실을 깨닫지 못했을 수도 있습니다.

커리를 사용하거나 다른 함수에 대한 인수로 함수를 전달할 때 OOP 언어에서 어떻게 수행하는지 생각하고 중지하십시오.

함수형 프로그래밍이 OOP 디자인 패턴이 필요 없다는 주장에 대한 진실이 있습니까?

네. :) FP 언어로 작업 할 때 더 이상 OOP 특정 디자인 패턴이 필요하지 않습니다. 그러나 여전히 MVC 또는 기타 비 OOP 관련 항목과 같은 일반적인 디자인 패턴이 필요하며 대신 새로운 FP 관련 "디자인 패턴"이 필요합니다. 모든 언어에는 단점이 있으며 디자인 패턴은 일반적으로 우리가 해결하는 방법입니다.

어쨌든 ML (최소한 개인적으로 좋아하는 학습 목적) 또는 Haskell 과 같은 "깨끗한"FP 언어 또는 Haskell 에서 손을 시험해 보는 것이 흥미로울 수 있습니다. 새로운 무언가에 직면 해 있습니다.

예상 한대로 몇몇 사람들은 "언어의 단점을 패치"하는 디자인 패턴에 대한 나의 정의에 반대했습니다.

이미 언급했듯이, 대부분의 디자인 패턴은 하나의 프로그래밍 패러다임 또는 때로는 하나의 특정 언어에 따라 다릅니다. 종종 패러다임 에만 존재 하는 문제를 해결합니다 (FP의 모나드 또는 OOP의 추상 팩토리 참조).

FP에 추상 팩토리 패턴이없는 이유는 무엇입니까? 해결하려는 문제가 존재하지 않기 때문입니다.

따라서 FP 언어에는없는 OOP 언어에 문제가 있으면 분명히 OOP 언어의 단점입니다. 문제를 해결할 수는 있지만 언어는 그렇지 않지만 문제를 해결하려면 상용구 코드가 필요합니다. 이상적으로, 우리는 프로그래밍 언어가 모든 문제 를 마술처럼 없애기 를 원합니다 . 여전히 존재하는 문제는 원칙적으로 언어의 단점입니다. ;)

함수형 프로그래밍이 OOP 디자인 패턴이 필요 없다는 주장에 대한 진실이 있습니까?

함수형 프로그래밍은 객체 지향 프로그래밍과 다릅니다. 객체 지향 디자인 패턴은 함수형 프로그래밍에는 적용되지 않습니다. 대신, 기능적인 프로그래밍 디자인 패턴이 있습니다.

함수형 프로그래밍의 경우 OO 디자인 패턴 북을 읽지 않습니다. FP 디자인 패턴에 대한 다른 책을 읽습니다.

언어에 구애받지 않는 언어

완전히 아닙니다. OO 언어와 관련하여 언어에 구애받지 않습니다. 디자인 패턴은 절차 적 언어에는 전혀 적용되지 않습니다. 관계형 데이터베이스 디자인 컨텍스트에서는 거의 의미가 없습니다. 스프레드 시트를 디자인 할 때는 적용되지 않습니다.

전형적인 OOP 디자인 패턴과 그에 상응하는 기능?

위의 내용이 존재하지 않아야합니다. OO 코드로 다시 작성된 절차 코드를 요구하는 것과 같습니다. 음 ... 원래 Fortran (또는 C)을 Java로 번역하면 번역 이상의 작업을 수행하지 않습니다. OO 패러다임으로 완전히 다시 쓰면 더 이상 원래 포트란이나 C와 같은 모양이 아닙니다. 인식 할 수 없습니다.

OO 디자인에서 기능적 디자인으로의 간단한 매핑은 없습니다. 그들은 문제를 보는 매우 다른 방법입니다.

함수형 프로그래밍 ( 모든 프로그래밍 스타일 과 마찬가지로 )에는 디자인 패턴이 있습니다. 관계형 데이터베이스에는 디자인 패턴이 있고 OO에는 디자인 패턴이 있으며 절차 적 프로그래밍에는 디자인 패턴이 있습니다. 모든 것은 디자인 패턴, 심지어 건축물의 아키텍처를 가지고 있습니다.

개념으로서의 디자인 패턴은 기술이나 문제 영역에 관계없이 영원한 구축 방법입니다. 그러나 특정 디자인 패턴은 특정 문제 영역 및 기술에 적용됩니다.

자신이하는 일을 생각하는 사람은 누구나 디자인 패턴을 발견 할 것입니다.

언어와 패턴 사이의 긴밀한 연계에 대한 Brian의 의견은 요점입니다.

이 토론에서 빠진 부분은 관용구의 개념입니다. James O. Coplien의 저서 "Advanced C ++"는 큰 영향을 미쳤습니다. 크리스토퍼 알렉산더와 이름없는 칼럼 을 발견하기 오래 전에 (알렉산더를 읽지 않고는 패턴에 대해 현명하게 이야기 할 수 없다), 그는 언어를 진정으로 배우는 관용구 숙달의 중요성에 대해 이야기했다. 그는 예를 들어 C에서 문자열 복사를 사용했습니다. while(*from++ = *to++);이 기능은 언어 기능 (또는 라이브러리 기능)이 누락 된 것에 대한 반창으로 볼 수 있지만 실제로 중요한 것은 생각보다 표현력이 더 크다는 것입니다. 그 부분.

그것이 우리의 의도를 더 간결하게 표현할 수 있도록 패턴과 언어가 시도하는 것입니다. 생각의 단위가 풍부할수록 당신이 표현할 수있는 생각이 더 복잡해집니다. 시스템 아키텍처에서 비트 트위들 링에 이르기까지 다양한 규모의 풍부하고 공유 된 어휘를 사용하면보다 지능적인 대화와 우리가해야 할 일에 대한 생각을 가질 수 있습니다.

또한 개인으로서도 배울 수 있습니다. 운동의 요점은 어느 것입니까? 우리는 결코 우리 자신을 생각할 수 없었던 것들을 이해하고 사용할 수 있습니다. 언어, 프레임 워크, 라이브러리, 패턴, 관용구 등은 모두 지적 재산을 공유 할 수 있습니다.

GoF 책은 명시 적으로 OOP와 관련이 있습니다. 제목은 디자인 패턴-재사용 가능한 객체 지향 소프트웨어의 요소 (강조 광산)입니다.

Peter Norvig의 동적 프로그래밍의 디자인 패턴 은 '기능적'대신 '동적'언어 (중복이 있음)에 대해이 일반적인 주제를 신중하게 다루었습니다.

이 주제를 논의하는 또 다른 링크가 있습니다 : http://blog.ezyang.com/2010/05/design-patterns-in-haskel/

Edward의 블로그 게시물에서 Edward는 Haskell과 관련하여 23 개의 원본 GoF 패턴을 모두 설명합니다.

이것을 "디자인 패턴"(일반적으로)과 "FP 대 OOP"수준에서 보려고하면 찾을 수있는 답변이 가장 어둡습니다.

하지만 두 축의 수준을 한 단계 더 높이고 특정 디자인 패턴 과 특정 언어 기능 및 상황이 더 명확 해지는 것을 고려하십시오 .

예를 들어, Visitor , Strategy , Command 및 Observer 와 같은 일부 특정 패턴 은 대수적 데이터 유형 및 패턴 일치 , 클로저 , 퍼스트 클래스 함수 등 의 언어를 사용할 때 확실히 변경되거나 사라집니다 . GoF 서적의 일부 다른 패턴 그래도 '고착'합니다.

일반적으로 시간이 지남에 따라 새로운 (또는 인기있는 언어) 언어 기능으로 특정 패턴이 제거되고 있다고 말할 수 있습니다. 이것은 언어 디자인의 자연스러운 과정입니다. 언어의 수준이 높아짐에 따라 이전에는 예제를 사용하여 책에서만 호출 할 수 있었던 추상화가 특정 언어 기능 또는 라이브러리의 응용 프로그램이되었습니다.

(제외 : 여기 내가 작성한 최근 블로그 가 있는데, 여기에는 FP 및 디자인 패턴에 대한 자세한 토론 링크가 있습니다.)

Norvig의 프레젠테이션은 모든 GoF 패턴에 대한 분석을 암시하며 23 개 패턴 중 16 개는 기능적 언어로 더 단순하게 구현되었거나 단순히 언어의 일부라고 말합니다. 아마도 그들 중 적어도 7 명은 a) 똑같이 복잡하거나 b) 언어에 존재하지 않았을 것이다. 불행히도 우리에게는 열거되지 않습니다!

GoF의 대부분의 "창조적"또는 "구조적"패턴은 Java 또는 C ++의 기본 유형 시스템을 사용하여 원하는 작업을 수행하는 데 유용한 기술 일뿐입니다. 그러나 나머지 언어는 프로그래밍 언어에 관계없이 고려할 가치가 있습니다.

하나는 프로토 타입 일 수 있습니다. JavaScript의 기본 개념이지만 다른 언어로 처음부터 구현해야합니다.

내가 가장 좋아하는 패턴 중 하나는 Null Object 패턴입니다. 적절한 종류의 아무것도 수행하지 않는 객체로 무언가가 없음을 나타냅니다. 기능적 언어로 모델링하기가 더 쉬울 수 있습니다. 그러나 실제 성과는 관점의 변화입니다.

매크로를 지원하는 Lisp와 같은 언어를 사용하면 일반 관용구 솔루션보다 훨씬 우수한 추상화를 도메인 고유의 추상화로 만들 수 있습니다.

심지어 OO 디자인 패턴 솔루션조차 언어에 따라 다릅니다.

디자인 패턴은 프로그래밍 언어로 해결할 수없는 일반적인 문제에 대한 솔루션입니다. Java에서 싱글 톤 패턴은 무언가 (단순화) 문제를 해결합니다.

스칼라에는 클래스 외에 Object라는 최상위 구조가 있습니다. 게으른 인스턴스화되고 하나만 있습니다. 싱글 톤을 얻기 위해 싱글 톤 패턴을 사용할 필요는 없습니다. 언어의 일부입니다.

패턴은 계속해서 또 다시 보여지고 설명되고 문서화되는 유사한 문제를 해결하는 방법입니다. 따라서 FP는 패턴을 대체하지 않습니다. 그러나 FP는 새 패턴을 작성하고 현재 "모범 사례"패턴을 "폐기"합니다.

다른 사람들이 말했듯이 함수형 프로그래밍에 특정한 패턴이 있습니다. 디자인 패턴을 제거하는 문제는 기능적으로 전환하는 것이 아니라 언어 기능 의 문제라고 생각합니다 .

"싱글 톤 패턴"으로 스칼라가 어떻게 사라지는 지 살펴보십시오 . 클래스 대신 객체 를 선언하기 만하면 됩니다. 또 다른 기능인 패턴 일치는 방문자 패턴의 혼란을 피하는 데 도움이됩니다. 여기에서 비교를보십시오 : Scala의 패턴 매칭 = 스테로이드의 방문자 패턴

그리고 F #과 마찬가지로 스칼라는 OO 기능의 융합입니다. F #에 대해서는 잘 모르지만 아마도 이런 종류의 기능이있을 것입니다.

클로저는 기능적 언어로 제공되지만 이에 제한 될 필요는 없습니다. 델리 게이터 패턴을 도와줍니다.

하나 더 관찰. 이 코드 조각은 패턴을 구현합니다. 그것은 고전적이며 매우 "원본"이라고 생각할 정도로 기본적입니다.

for(int i = 0; i < myList.size(); i++) { doWhatever(myList.get(i)); }

Java 및 C #과 같은 명령형 언어는이를 처리하기 위해 본질적으로 기능적 구성 인 "foreach"를 채택했습니다.

GoF 디자인 패턴 은 Java 및 C ++와 같이 Simula 67의 자손 인 OO 언어에 대한 해결 방법을 코딩 합니다.

디자인 패턴으로 처리되는 대부분의 "질병"은 다음과 같은 원인에 의해 발생합니다.

• 객체를 지정하지만 그 자체가 객체가 아닌 정적으로 유형이 지정된 클래스;
• 단일 디스패치에 대한 제한 (가장 왼쪽 인수 만 메소드를 선택하는 데 사용되며 나머지 인수는 정적 유형으로 만 간주됩니다. 동적 유형이있는 경우 임시 접근 방식으로 정렬하는 방법은 메소드에 달려 있습니다).
• 정규 함수 호출과 객체 지향 함수 호출의 구분, 즉 객체 지향 함수는 정규 함수가 예상되는 기능 인수로 전달 될 수 없으며 그 반대도 마찬가지입니다. 과
• "기본 유형"과 "클래스 유형"의 구별.

솔루션이 해당 디자인 패턴과 기본적으로 동일한 방식으로 구성되어 있어도 공통 Lisp 오브젝트 시스템에서 사라지지 않는 이러한 디자인 패턴 중 하나는 없습니다. 또한이 객체 시스템은 GoF 책보다 10 년 이상 앞서 있습니다. Common Lisp는 해당 책이 처음 출판 된 해와 같은 해 ANSI 표준이되었습니다.

함수형 프로그래밍에 관한 한, 패턴의 적용 여부는 주어진 함수형 프로그래밍 언어에 어떤 종류의 객체 시스템이 있는지 여부와 패턴에서 혜택을받는 객체 시스템을 따라 모델링되는지 여부에 따라 달라집니다. 이러한 유형의 객체 지향은 상태의 돌연변이가 전면과 중앙에 있기 때문에 기능적 프로그래밍과 잘 혼합되지 않습니다.

구성 및 비변이 액세스는 기능적 프로그래밍과 호환되므로 추상 액세스 또는 구성과 관련된 패턴 (공장, 외관, 프록시, 데코레이터 및 방문자와 같은 패턴)을 적용 할 수 있습니다.

반면, 상태 및 전략과 같은 행동 패턴 은 상태의 돌연변이가 핵심이므로 기능적 OOP에 직접 적용 되지 않을 수 있습니다. 그렇다고해서 적용하지 않는 것은 아닙니다. 아마도 변경 가능한 상태를 시뮬레이션하는 데 사용할 수있는 트릭과 함께 적용 할 수 있습니다.

Jeremy Gibbons의 "고급 데이터 유형-일반 프로그램으로서의 디자인 패턴"과 "반복자 패턴의 본질"( http : // www. comlab.ox.ac.uk/jeremy.gibbons/publications/ ).

이것들은 관용적 기능 구성이 다른 (객체 지향) 설정에서 특정 디자인 패턴으로 덮힌 지형을 어떻게 다루는 지 설명합니다.

타입 시스템을 불러 오지 않으면이 토론을 할 수 없습니다.

함수형 프로그래밍의 주요 기능에는 일류 값, 카레, 불변 값 등의 함수가 포함됩니다. OO 디자인 패턴이 이러한 기능 중 하나에 가깝다는 것은 분명하지 않습니다.

이러한 기능은 OOP와 동일한 문제를 해결하지 못하기 때문에 명령형 프로그래밍의 대안입니다. OOP에 대한 FP 답변은 ML 및 Haskell의 유형 시스템에 있습니다. 특히 합계 유형, 추상 데이터 유형, ML 모듈 및 Haskell 유형 클래스입니다.

그러나 FP 언어로 해결되지 않은 디자인 패턴이 여전히 있습니다. FP는 싱글 톤과 동일합니까? (단일 톤이 일반적으로 사용하기에 끔찍한 패턴이라는 점을 무시하십시오)

타입 클래스가하는 첫 번째 일은 싱글 톤의 필요성을 없애는 것입니다.

23의 목록을 살펴보고 더 많은 것을 제거 할 수는 있지만 지금 당장은 시간이 없습니다.

기능성 프로그래밍 로직을 자연스러운 OO 언어로 도입하기 위해 2 개의 GoF 디자인 패턴 만 설계되었다고 생각합니다. 전략과 지휘에 대해 생각합니다. 다른 GoF 디자인 패턴 중 일부는 기능 프로그래밍을 통해 수정하여 디자인을 단순화하고 목적을 유지할 수 있습니다.

본질적으로 그렇습니다 !

• 패턴이 누락 된 피처 (고차 함수, 스트림 처리 ...)를 우회하는 경우 촉진 조성물 .
• 패턴 구현을 반복해서 다시 작성해야 할 필요성은 언어 냄새 로 볼 수 있습니다. .

또한이 페이지 (AreDesignPatternsMissingLanguageFeatures) 는 "패턴 / 기능"번역 테이블과 유용한 설명을 제공합니다.

함수형 프로그래밍은 디자인 패턴을 대체하지 않습니다. 디자인 패턴을 교체 할 수 없습니다.

패턴은 단순히 존재합니다. 그들은 시간이 지남에 따라 나타났다. GoF 책은 그들 중 일부를 공식화했습니다. 개발자가 흥미 진진한 기능적 프로그래밍 언어를 사용함에 따라 새로운 패턴이 밝혀지면 아마도 그들에 관한 책도있을 것입니다.

"Scala 및 Clojure의 기능 프로그래밍 패턴-" 이라는 새로운 2013 년 책 에서 에서 저자 Michael.B. Linn은 많은 경우 GoF 패턴을 대체하고 대체하는 적절한 작업을 수행하며 '꼬리 재귀', '기억', '지연 시퀀스'등과 같은 최신 기능 패턴에 대해서도 설명합니다.

이 책은 아마존에서 구할 수 있습니다. 나는 수십 년의 OO 배경에서 올 때 매우 유익하고 고무적이라는 것을 알았습니다.

OOP 및 GoF 패턴은 상태를 처리합니다. OOP는 코드 기반을 가능한 현실의 요구 사항에 최대한 가깝게 유지하기 위해 현실을 모델링합니다. GoF 디자인 패턴은 원자 현실 문제를 해결하기 위해 식별 된 패턴입니다. 그것들은 의미 론적으로 상태의 문제를 처리합니다.

실제 기능 프로그래밍에서와 같이 상태가 존재하지 않으므로 GoF 패턴을 적용하는 것은 의미가 없습니다. GoF 디자인 패턴과 같은 방식으로 기능적인 디자인 패턴이 없습니다. 함수는 현실이 아니라 수학의 구조이므로 모든 기능적 디자인 패턴은 현실과 대조적으로 인공적입니다.

함수가 시간이 함수 매개 변수의 일부가 아닌 한 "미래 요청"을 수행하기 어렵게 만드는 경우가 아니라면 현재 시간에 관계없이 항상 같은 값을 반환하므로 함수에는 시간 개념이 없습니다. 하이브리드 언어는 이러한 개념을 혼합하여 실제 기능 프로그래밍 언어가 아닌 언어를 만듭니다.

기능 언어는 현재 물리학의 자연적 제한이라는 한 가지 이유로 만 떠오르고 있습니다. 오늘날의 프로세서는 물리적 법률로 인해 처리 명령 속도가 제한되어 있습니다. 클럭 주파수에는 정체가 있지만 처리 코어에는 확장이 있습니다. 이것이 현대 응용 프로그램의 속도를 높이기 위해 명령의 병렬 처리가 점점 더 중요 해지는 이유입니다. 정의에 따른 기능적 프로그래밍은 상태가 없으므로 부작용이 없으므로 기능을 안전하게 병렬로 처리하는 것이 안전합니다.

GoF 패턴은 더 이상 사용되지 않습니다. 실제 요구 사항을 모델링하려면 최소한 필요합니다. 그러나 함수형 프로그래밍 언어를 사용하는 경우 해당 언어를 하이브리드로 변환해야합니다. 마지막으로 지속성을 사용하면 기능적인 프로그램 만 만들 기회가 없습니다. 프로그램의 하이브리드 요소에는 GoF 패턴을 사용해야 할 필요성이 남아 있습니다. 순전히 기능하는 다른 요소의 경우 상태가 없기 때문에 GoF 패턴을 사용할 필요가 없습니다.

실제 기능 프로그래밍에는 GoF 패턴이 필요하지 않기 때문에 SOLID 원칙을 적용해서는 안됩니다. SOLID의 원칙은 모든 언어 패러다임을 넘어선 것입니다.

함수형 프로그래밍에서 디자인 패턴은 다른 의미를 갖습니다. 실제로, 대부분의 OOP 디자인 패턴은 빌딩 블록으로 사용되는 더 높은 수준의 추상화 및 HOF로 인해 기능 프로그래밍에서 필요하지 않습니다 .

HOF의 원리는 함수가 다른 함수에 대한 인수로 전달 될 수 있음을 의미합니다. 함수는 값을 반환 할 수 있습니다.

허용되는 답변에서 알 수 있듯이 OOP와 FP에는 모두 고유 한 패턴이 있습니다.

그러나 내가 생각할 수있는 모든 프로그래밍 플랫폼에 있어야 할 공통 패턴이 있습니다. 다음은 (불완전한) 목록입니다.

• 어댑터. 전 세계와 대화 할 필요가없는 포괄적 인 (및 자체 충족 된) 유용한 프로그래밍 플랫폼을 거의 생각할 수 없습니다. 그렇게하려면 어댑터가 반드시 필요합니다.

• 정면. 큰 소스 코드를 처리 할 수있는 모든 프로그래밍 플랫폼은 모듈화 할 수 있어야합니다. 프로그램의 다른 부분에 대한 모듈을 만들려면 코드의 "더러운"부분을 숨기고 멋진 인터페이스를 제공해야합니다.

• 통역사. 일반적으로 모든 프로그램은 구문 분석 입력 및 인쇄 출력의 두 가지 작업을 수행합니다. 마우스 입력을 구문 분석하고 창 위젯을 인쇄해야합니다. 따라서, 인터프리터가 내장되어 있으면 프로그램을 사용자 정의 할 수있는 추가 기능이 제공됩니다.

또한 전형적인 FP 언어 인 Haskell에서 GoF 패턴과 유사하지만 이름이 다른 것을 발견했습니다. 제 생각에는 FP 및 OOP 언어에서 해결해야 할 몇 가지 일반적인 문제가 있기 때문에 이것이 존재한다고 생각합니다.

• 모나드 변압기 및 데코레이터. 전자는 기존 모나드에 추가 기능을 추가하고 후자는 기존 객체에 추가 기능을 추가했습니다.

각 패러다임은 다른 목적으로 사용되므로 이런 방식으로 비교할 수 없다고 생각합니다.

GoF 디자인 패턴이 모든 언어에 적용될 수 있다고 들었습니다. 모든 OOP 언어에 적용 할 수 있다고 들었습니다. . 함수형 프로그래밍을 사용하면 해결하는 문제 영역이 OO 언어와 다릅니다.

사용자 인터페이스를 작성하기 위해 기능적 언어를 사용하지는 않지만 C # 또는 Java와 같은 OO 언어 중 하나 가이 작업을 더 쉽게 만듭니다. 기능적 언어를 쓰고 있다면 OO 디자인 패턴 사용을 고려하지 않을 것입니다.

OOP와 FP의 목표는 다릅니다. OOP는 소프트웨어 구성 요소의 복잡성 / 이동 부분을 캡슐화하는 것을 목표로하고 FP는 소프트웨어 구성 요소의 복잡성과 종속성을 최소화하는 것을 목표로합니다.

그러나이 두 패러다임이 반드시 100 % 모순되는 것은 아니며 두 세계의 혜택을 얻기 위해 함께 적용될 수 있습니다.

C #과 같은 함수형 프로그래밍을 기본적으로 지원하지 않는 언어를 사용하더라도 FP 원칙을 이해하면 함수형 코드를 작성할 수 있습니다. 마찬가지로 OOP 원칙, 패턴 및 모범 사례를 이해하면 F #을 사용하여 OOP 원칙을 적용 할 수 있습니다. 사용하는 프로그래밍 언어에 관계없이 해결하려는 상황과 문제에 따라 올바른 선택을해야합니다.

일부 패턴은 FP를 지원하는 언어로 구현하기가 더 쉽습니다. 예를 들어, 클로저를 사용하여 전략을 구현할 수 있습니다. 그러나 상황에 따라 클래스 기반 접근 방식을 사용하여 전략을 구현하는 것을 선호 할 수 있습니다. 전략 자체가 매우 복잡한 위치 및 / 또는 템플릿 방법을 사용하여 모델링하려는 구조를 공유하십시오.

다중 패러다임 언어 (Ruby)로 개발 한 경험에서 FP 구현은 간단한 경우에는 잘 작동하지만 컨텍스트가 더 복잡한 경우 GoF OOP 기반 접근 방식이 더 적합합니다.

FP 접근 방식은 OOP 접근 방식을 대체하지 않으며이를 보완합니다.

함수형 프로그래밍 IMHO의 가장 중요한 특징은 표현식 만으로 프로그래밍한다는 것입니다. 모두 "따뜻하게 평가 시스템을"그 마지막, 최종 표현에 평가하는 것이 표현 내에서 표현 내에서 표현 -.

객체 지향 프로그래밍 IMHO의 가장 중요한 특징은 내부 상태의 객체를 사용하여 프로그래밍하는 것입니다. 순수한 함수에서는 내부 상태를 가질 수 없습니다. 객체 지향 프로그래밍 언어에는 명령문이 필요합니다 . 는 일을 수행하기 위해 이 . (함수 프로그래밍에는 문장이 없습니다.)

사과와 오렌지를 비교하고 있습니다. 함수형 프로그래밍은 표현식으로 프로그래밍하고 객체 지향형 프로그래밍은 내부 상태로 프로그래밍하기 때문에 객체 지향 프로그래밍의 패턴은 함수 프로그래밍에 적용되지 않습니다.

마음 단단히 먹어.

디자인 패턴을 교체하고 SOLID 및 DRY를 손상 시켰다는 주장을 듣고 많은 사람들을 괴롭힐 것입니다. 나는 보잘것 없다. 그럼에도 불구하고, 나는 협업 (제조) 아키텍처를 올바르게 모델링하고 내 웹 사이트 http://www.powersemantics.com/ 에서 코드 및 과학과 함께 프로세스를 구축하는 규칙을 온라인으로 게시했습니다 . .

필자는 디자인 패턴이 제조 과정에서 "대량 맞춤화"라고 부르는 모든 단계를 재구성, 재구성 및 확장 할 수있는 프로세스 형식을 달성하려고 노력한다고 주장했다. 이러한 프로세스는 컴파일되지 않은 스크립트로 생각할 수 있습니다. 나는 여기서 (온라인) 논증을 반복하지 않을 것이다. 요컨대, 대량 사용자 정의 아키텍처는 복잡한 의미없이 유연성을 달성하여 디자인 패턴을 대체합니다. 모델이 잘 작동한다는 사실에 놀랐지 만 프로그래머가 코드를 작성하는 방식은 제조가 협업 작업을 구성하는 방법에 초를 두지 않습니다.

• 제조 = 각 단계는 하나의 제품과 상호 작용
• OOP = 각 단계는 자신과 다른 모듈과 상호 작용하여 쓸모없는 회사원처럼 제품을 다른 곳으로 전달합니다.

이 아키텍처는 리팩토링이 필요하지 않습니다. 복잡성에 영향을 미치는 중앙 집중화 및 배포와 관련된 규칙도 있습니다. 그러나 귀하의 질문에 대답하기 위해, 기능적 프로그래밍은 또 다른 처리 의미론 세트입니다 .1) 소스 라우팅이 (배우기 전에 다시 작성할 수있는 스크립트) 문서로 존재하고 2) 모듈을 쉽게 동적으로 추가 또는 제거

우리는 OOP가 "하드 코딩 된 프로세스"패러다임이라고 말할 수 있으며 디자인 패턴은 그러한 패러다임을 피하는 방법입니다. 그러나 이것이 대량 사용자 정의에 관한 것입니다. 디자인 패턴은 역동적 인 프로세스를 지저분한 하드 코드로 구현합니다. 아무 의미가 없습니다. F #에서 함수를 매개 변수로 전달할 수 있다는 사실은 함수형 언어 와 OOP 언어가 모두 대량 사용자 지정 자체를 달성하려는 시도를 의미 합니다.

스크립트를 나타내는 하드 코드 인 독자에게는 그 점이 얼마나 혼란 스럽습니까? 컴파일러의 소비자가 그러한 기능에 대해 비용을 지불한다고 생각한다면 전혀 그렇지 않지만 그러한 기능은 의미 상 낭비입니다. 대량 사용자 지정 시점은 Visual Studio를 사용하는 프로그래머에게 역동적 인 것이 아니라 프로세스 자체를 역동적 으로 만드는 것이므로 의미가 없습니다.

OCaml과 같은 클래스, 모듈 등의 고급 기능 PL은 유형 다양성과 표현력면에서 OOP 명령 언어를 확실히 대체합니다. 추상화는 누출되지 않으며 대부분의 아이디어를 프로그램에서 직접 표현할 수 있습니다. 따라서 디자인 패턴을 대체합니다. 기능 패턴과 비교할 때 대부분 단순합니다.