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

인용 한 블로그 게시물의 소유권 주장이 약간 과장되었습니다. 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 언어의 단점입니다. 문제를 해결할 수는 있지만 언어는 그렇지 않지만 문제를 해결하려면 상용구 코드가 필요합니다. 이상적으로, 우리는 프로그래밍 언어가 모든 문제 를 마술처럼 없애기 를 원합니다 . 여전히 존재하는 문제는 원칙적으로 언어의 단점입니다. 😉

---

답변