대규모 기능적 프로그래밍 응용 프로그램을 만드는 데 일반적으로 사용되는 특정 워크 플로 또는 디자인 패턴이 있습니까? [닫은]


13

나는 Clojure를 잠시 동안 탐색 해 왔지만, 사소한 프로젝트에서는 사용하지 않았지만. 기본적으로 구문과 일부 관용구에 익숙해졌습니다. Clojure가 내가 가장 많이 살펴본 첫 번째 기능 언어 인 OOP 배경에서 비롯된 나는 자연스럽게 기능적인 방식으로 일을하는 것에 익숙하지 않다.

즉, 대규모 기능의 응용 프로그램을 만드는 데 공통적 인 특정 워크 플로 또는 디자인 패턴이 있습니까? "실제로"함수형 프로그래밍을 사용하고 싶지만 현재의 전문 지식이 부족하여 서사시가 실패 할까봐 두렵습니다.

"Gang of Four"는 OO 프로그래머를위한 표준이지만 기능적 패러다임에 더 유사한 것이 있습니까? 내가 찾은 대부분의 리소스에는 훌륭한 프로그래밍 너겟이 있지만 더 넓고 건축적인 모습을 보여주기 위해 뒤로 물러서지 않습니다.


6
일부 GOF 패턴은 실제로 Functional Programming이 이미 제공 한 것들에 대한 OO 언어의 해결 방법입니다. stackoverflow.com/q/327955
Robert Harvey



이 토론에서 GoF / OOP 관련 패턴에 너무 많은 초점이 있다고 생각합니다. 누구나 실제 기능적 프로그래밍 관련 패턴을 게시 할 수 있습니까 (기능적 언어로 GoF의 사소함을 증명하려는 것이 아님)?
Daniel B

답변:


3

이러한 종류의 패턴은 일반적으로 파손되고 적합하지 않은 기본 모델의 증상입니다.

OOP는 설계 상으로 깨져서 대부분의 응용 분야에 적합하지 않으므로 소위 "패턴"이라고 부릅니다. 기능적 모델은 약간 유연하고 "패턴"의 필요성은 그다지 명백하지 않습니다.

각 특정 문제 도메인에 대해 DSL을 사용하거나 작성하여 (기능 프로그래머에게 자연스러운) 언어 지향 접근법을 적용하기 시작하면 항상 적절한 모델을 사용하기 때문에 패턴이 전혀 표시되지 않습니다. 문제 설명.

물론 매우 추상적이고 깨끗하며 순수한 수학에서도 되풀이되는 높은 수준의 "패턴"또는 "레시피"는 피할 수 없지만 GoF 패턴과는 다른 종류와 다른 추상화 수준입니다. 예를 들어 모나드가 유용하다는 것을 알게 될 것입니다.


마지막 두 단락에 대해 +1, 나는 그 자리에 있다고 생각합니다. OOP와 관련하여, 나는 그것이 특정 문제에 종종 적용되는 일반적인 도구라는 사실 외에 (고프 패턴과 같은 저수준 패턴이 존재 함) 사실을 제외하고는 그것을 부러 뜨렸다는 이론적 근거에 대해 궁금합니다. 간략하게 설명하거나 의견을 요약 한 링크를 게시 할 수 있습니까?
Daniel B

@DanielB, OOP 자체에는 아무런 문제가 없지만 일반적으로 적용되는 방식이 완전히 손상되었습니다. 이 모델은 실제 문제 중 일부에만 적합하며 (적절하게 적용하면 실제로 빛납니다) 나머지는 목발과 덕트 테이프가 모두 맞아야합니다. 예를 들어 programmers.stackexchange.com/questions/52608/… 에서 내 대답을 참조하십시오 .
SK-logic

좋아, 나는 같은 페이지에 있다고 생각한다. 사실, 나는이 정확한 질문을 한 번 전에 물었을 수도 있습니다. 미안합니다.
Daniel B

-3

개인적으로는 디자인 패턴이 의미 론적이라고 생각합니다. 내가 생각했던 것뿐만 아니라 패턴을 이해했는지 확인하기 위해 MVC를 사용하여 오래된 앱을 다시 작성하는 것을 기억합니다. 그러나 결국 MVC에서 원래 코드보다 아무것도 얻지 못했습니다.

그러나 원래 코드를 더 큰 개발 환경에 적용하고 누군가 에게이 특정 방법에 문제가 있다고 말하면 해당 개발자가 문제를 추적하기가 어려울 것입니다. 그러나 ContractController가 어떤 이유로 인해 막혔다 고 말하면 정확히 어디서 시작해야하는지 알게 될 것입니다.

디자인 패턴은 훌륭하지만 ... 말했듯이 의미가 있다고 생각합니다!

편집 : 당신은 전도자 유형이 나를 깨뜨립니다. MVC (또는 다른 디자인 패턴)없이 어떻게 개발 되었습니까?


2
시맨틱 (sɪˈmæntɪk) — adj 1. 다른 단어 나 기호의 의미 사이의 구별 또는 의미로 인해 발생하는 의미 2. 또는 의미론과 관련된 의미 (의미 연구) 3. 형식 이론의 해석과 관련된 논리, 진실 표가 문장 적 연결의 설명으로 주어질 때
Robert Harvey

+1-제 요점은 디자인 패턴이 단순히 의사 소통 수단이라는 것입니다!
aserwin

디자인 패턴은 단순한 의사 소통 방법 이상입니다. 그것들은 일반적으로 자주 발생하는 특정 문제를 해결하기 위해 소프트웨어로 구현 될 수있는 구체적이고 이해하기 쉬운 레시피입니다.
Robert Harvey

그것이 책이 말하는 것입니다. 그러나 실제로는 해결할 수 없었던 디자인 패턴을 통해 문제를 해결 한 적이 없습니다. 내 경험에서 알 수있는 유일한 이점은 코드에 대해 서로 대화 할 수 있다는 것입니다! ;)
aserwin

1
편집 관련 : 새로운 코드를 작성할 때마다 휠을 다시 발명하고 싶습니까?
Robert Harvey
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.