컴퓨터 언어 (예 : 0110101000110101컴퓨터 언어)는 일반적으로 상위 형태의 추상화로 발전해 왔으므로 일반적으로 문제에 적용될 때 코드를 이해하기가 더 쉽습니다. 어셈블러는 머신 코드에 대한 추상화 였고 C는 어셈블러에 대한 추상화였습니다.
객체 지향 디자인은 객체 측면에서 문제를 모델링하는 데 매우 능숙한 것으로 보입니다. 예를 들어 대학 과정 등록 시스템의 문제는 Course클래스, Student클래스 등 으로 모델링 할 수 있습니다 . 그런 다음 솔루션을 작성할 때 OO 언어로, 우리는 책임을지고 일반적으로 디자인, 특히 코드 모듈화에 도움이되는 비슷한 클래스를 가지고 있습니다. OO 방법으로 문제를 해결하는 10 명의 독립적 인 팀에이 문제를 주면 일반적으로 10 가지 솔루션에 공통적으로 문제와 관련된 클래스가 있습니다. 이러한 클래스의 커플 링 및 상호 작용을 시작할 때 많은 차이가있을 수 있으므로 "제로 표현 간격"과 같은 것은 없습니다.
함수형 프로그래밍에 대한 나의 경험은 매우 제한적입니다 (실제로 사용하지 않고 Hello World 형식의 프로그램 만). 나는 그러한 언어가 어떻게 FP 솔루션을 OO 언어와 같은 문제 (낮은 표현 간격)로 쉽게 매핑 할 수 있는지 알지 못했습니다.
동시 프로그래밍과 관련하여 FP의 장점을 이해합니다. 그러나 나는 무엇인가 빠졌습니까, 아니면 FP는 표현 격차를 줄이는 것이 아닙니다 (솔루션을 이해하기 쉽게 만듭니다)?
이것을 묻는 또 다른 방법 : 같은 실제 문제를 해결하는 10 개의 서로 다른 팀의 FP 코드가 공통점이 많습니까?
Wikipedia on Abstraction (컴퓨터 과학) (강조 광산)에서 :
함수형 프로그래밍 언어는 일반적 으로 람다 추상화 (일부 변수의 함수로 용어 만들기), 고차 함수 (매개 변수는 함수), 괄호 추상화 (항을 변수의 함수로 만들기) 와 같은 함수와 관련된 추상화를 나타냅니다 .
[일부] 실제 문제는 그러한 추상화로 쉽게 모델링되지 않기 때문에 표현 격차가 잠재적으로 증가 할 수 있습니다.
표현 격차가 줄어드는 또 다른 방법은 솔루션 요소를 다시 문제로 추적하는 것입니다. 0의와 1기계 코드 S는 반면, 역 추적하는 것은 매우 어려운 Student클래스는 추적 뒷면에 용이하다. 모든 OO 클래스가 문제 공간을 쉽게 추적하지는 않지만 많은 클래스가 문제 공간을 쉽게 추적합니다.
FP 추상화가 항상 문제 영역의 어느 부분을 해결하기 위해 설명해야 할 필요는 없습니까 ( 수학 문제 제외 )?OK-나는이 부분에 능숙하다. 더 많은 예제를 살펴본 후, 데이터 처리에서 표현되는 문제의 일부에 대해 FP 추상화가 어떻게 매우 명확한 지 알 수 있습니다.
관련 질문에 대한 대답 정답 UML을 사용하여 기능 프로그램을 모델링 할 수 있습니까? "기능 프로그래머는 다이어그램을 많이 사용하지 않습니다." UML인지는 신경 쓰지 않지만 널리 사용되는 다이어그램이없는 경우 (이 답변이 정확하다고 가정) FP 추상화가 이해하기 쉽고 의사 소통이되는지 궁금합니다. 다시 한 번, FP 사용 / 이해 수준은 사소한 것이므로 간단한 FP 프로그램에 대한 다이어그램이 필요하지 않다는 것을 이해합니다.
OO 디자인에는 기능 / 클래스 / 패키지 수준의 추상화가 있으며 각각에 캡슐화 (액세스 제어, 정보 숨기기) 기능이있어 관리가 더 쉽습니다. 이것들은 문제에서 해결책으로 나아가고 더 쉽게 돌아갈 수있게 해주는 요소입니다.
많은 답변에서 OO와 유사한 방식으로 FP에서 분석 및 디자인이 수행되는 방식에 대해 이야기하지만 아무도 지금까지 높은 수준의 내용을 인용 한 사람은 없습니다. 어제 많은 인터넷 검색을 수행하고 흥미로운 토론을 찾았습니다. 다음은 Simon Thompson (2004)의 리팩토링 기능 프로그램 (강조 광산)의 내용입니다.
객체 지향 시스템을 설계 할 때는 설계가 프로그래밍보다 우선합니다. 디자인은 Eclipse와 같은 도구에서 지원되는 UML과 같은 시스템을 사용하여 작성됩니다. 초보자는 BlueJ와 같은 시스템을 사용하여 시각적 디자인 접근 방식을 배울 수 있습니다. 기능 프로그래밍을위한 유사한 방법론에 대한 작업은 FAD : Functional Analysis and Design 에보고되어 있지만 다른 작업은 거의 없습니다. 여기에는 여러 가지 이유가있을 수 있습니다.
기존 기능 프로그램은 규모가 크므로 디자인이 필요하지 않습니다. 많은 기능적 프로그램은 작지만 Glasgow Haskell Compiler와 같은 다른 프로그램도 상당합니다.
기능적 프로그램은 응용 프로그램 도메인을 직접 모델링하므로 설계와 관련이 없습니다. 함수형 언어는 다양한 강력한 추상화를 제공하지만 실제 세계를 모델링하는 데 필요한 추상화 만 제공한다고 주장하기는 어렵습니다.
기능적 프로그램은 진화하는 일련의 프로토 타입으로 제작됩니다.
에서 박사 학위 논문 위에서 언급 , 분석 및 설계 방법론 (ADM)를 사용의 장점은 패러다임의 독립적 인 설명되어 있습니다. 그러나 ADM이 구현 패러다임과 일치해야한다는 주장이 제기되었습니다. 즉, OOADM은 OO 프로그래밍에 가장 적합하며 FP와 같은 다른 패러다임에는 잘 적용되지 않습니다. 다음은 내가 표현상의 차이라고 부르는 것을 역설이라고 생각하는 큰 인용문입니다.
어떤 패러다임이 소프트웨어 개발을위한 최고의 지원을 제공하는지에 관해 오랫동안 논할 수는 있지만, 문제 설명에서 구현 및 전달에 이르는 단일 패러다임 내에 남아있을 때 가장 자연스럽고 효율적이며 효과적인 개발 패키지를 달성 할 수 있습니다.
FAD가 제안한 다이어그램 세트는 다음과 같습니다.
- 구현에 사용되는 기능을 제공하는 기능 의존성 다이어그램;
- 유형에 대해 동일한 서비스를 제공하는 유형 종속성 다이어그램. 과,
- 시스템의 모듈 아키텍처에 대한 뷰를 제공하는 모듈 종속성 다이어그램.
축구 (축구) 리그와 관련된 데이터의 생산을 자동화하는 시스템 인 FAD 논문의 섹션 5.1에 사례 연구가 있습니다. 요구 사항은 100 % 기능적입니다 (예 : 축구 결과 입력, 리그 테이블 생성, 득점 테이블, 출석 테이블, 팀 간 선수 이동, 새로운 결과 후 데이터 업데이트 등) FAD가 작동하지 않는 요구 사항을 해결하는 방법에 대한 언급은 없습니다. "최소한의 비용으로 새로운 기능을 허용해야한다"는 것 외에는 테스트하기가 거의 불가능합니다.
안타깝게도 FAD와는 별도로 FP에 제안 된 모델링 언어 (시각적)에 대한 최신 참조는 없습니다. UML은 또 다른 패러다임이므로이를 잊어야합니다.