방금 처음으로 읽은 시스템을 모듈로 분해하는 데 사용되는 기준에 관한 고전 기사가 있습니다 . 그것은 나에게 완벽하게 이해되며 아마도 OOP가 기반으로 한 기사 중 하나 일 것입니다. 결론 :

이러한 예를 통해 플로우 차트를 기반으로 시스템을 모듈로 분해하는 것이 거의 항상 올바르지 않음을 보여 주려고 시도했습니다. ... 그런 다음 각 모듈은 그러한 결정을 다른 모듈로부터 숨기도록 설계되었습니다.

교육받지 않고 경험이없는 의견으로는, 함수형 프로그래밍은이 기사와 완전히 반대되는 조언을합니다. 내 이해는 함수형 프로그래밍이 데이터 흐름을 관용적으로 만듭니다. 데이터는 함수마다 전달되며 각 함수는 데이터를 밀접하게 인식하고 그 과정에서 "변경" 합니다. 그리고 나는 데이터 숨기기가 과대하거나 불필요하거나 어떻게 다른지에 대해 이야기하는 Rich Hickey의 이야기를 보았지만 확실히 기억할 수는 없습니다.

1. 먼저 평가가 올바른지 알고 싶습니다. FP 패러다임과이 기사는 철학적으로 동의하지 않습니까?
2. 그들이 동의하지 않는다고 가정 할 때, FP는 데이터 숨기기 부족에 대해 어떻게 "보상"합니까? 아마도 그들은 데이터 숨기기를 희생하지만 X, Y 및 Z를 얻습니다. X, Y 및 Z가 데이터 숨기기보다 더 유익한 이유를 알고 싶습니다.
3. 또는 그들이 동의하지 않는다고 가정하면, 아마도 FP는 데이터 숨기기가 나쁘다고 생각할 것입니다. 그렇다면 왜 데이터 숨기기가 나쁘다고 생각합니까?
4. 그들이 동의한다고 가정하면 데이터 숨기기의 FP 구현이 무엇인지 알고 싶습니다. OOP에서 이것을 볼 수 있습니다. private수업 외부의 누구도 액세스 할 수없는 필드를 가질 수 있습니다. FP에서 나에게 이것에 대한 명백한 비유는 없습니다.
5. 물어봐야 할 다른 질문이 있다고 생각하지만 물어봐야 할 것을 모르겠습니다. 그들도 자유롭게 대답하십시오.

최신 정보

나는이 발견 닐 포드 이야기 그것은 매우 관련 슬라이드를 가지고있다. 스크린 샷을 여기에 포함시킵니다.

언급 한 기사는 일반적으로 모듈성에 관한 것이며, 구조적, 기능적, 객체 지향 프로그램에도 동일하게 적용됩니다. 나는 OOP의 큰 사람이었던 사람으로부터 그 기사를 들었다. 그러나 나는 OOP에 특정한 것이 아니라 일반적인 프로그래밍에 관한 기사로 읽었다. 함수형 프로그래밍, 왜 함수형 프로그래밍이 중요한지 에 대한 유명한 기사 가 있으며 결론의 첫 문장은 "이 백서에서는 모듈화가 성공적인 프로그래밍의 열쇠라고 주장했습니다." 따라서 (1)에 대한 답은 '아니오'입니다.

잘 설계된 함수는 필요한 것보다 데이터에 대해 더 많은 것을 가정하지 않으므로 "데이터를 정확히 인식하는"부분은 잘못되었습니다. (또는 최소한 OOP의 경우와 마찬가지로 잘못되었습니다. 엄격하게 높은 수준의 추상화로 프로그래밍 할 수 없으며 모든 패러다임에서 모든 세부 사항을 영원히 무시할 수 없습니다. 결국 프로그램의 일부는 실제로 데이터의 특정 세부 사항.)

데이터 숨기기는 OOP 관련 용어이며 기사에서 논의 된 정보 숨기기와 정확히 동일하지 않습니다. 이 기사에 숨겨져있는 정보는 설계 결정이 어렵거나 변경 될 수있는 디자인 결정에 관한 것입니다. 데이터 형식에 대한 모든 디자인 결정이 어렵거나 변경 될 수있는 것은 아니며, 어렵거나 변경 될 수있는 모든 결정이 데이터 형식에 관한 것은 아닙니다. 개인적으로, OO 프로그래머가 왜 모든 것이 객체가 되기를 원하는지 알 수 없습니다 . 때로는 간단한 데이터 구조 만 있으면됩니다.

편집 : Rich Hickey와의 인터뷰 에서 관련 견적을 찾았습니다 .

포 거스 : 그 아이디어에 따라 일부 사람들은 Clojure가 데이터 숨김 캡슐화 유형에 관여하지 않는다는 사실에 놀랐습니다. 데이터 숨기기를 포기하기로 결정한 이유는 무엇입니까?

Hickey : Clojure는 추상화에 대한 프로그래밍을 강력하게 강조합니다. 그러나 어느 시점에서 누군가는 데이터에 액세스 할 수 있어야합니다. 그리고 "개인"이라는 개념이 있다면, 특권과 신뢰에 상응하는 개념이 필요합니다. 그리고 그것은 복잡성과 가치가 거의 없어 시스템에 강성을 만들고 종종 원하지 않는 곳에 살도록 강요합니다. 이것은 간단한 정보를 클래스에 넣을 때 발생하는 다른 손실에 추가됩니다. 데이터가 변경 불가능한 범위 내에서, 누군가가 변경 될 수있는 것에 의존 할 수있는 것 외에는 액세스를 제공 할 때 발생할 수있는 피해는 거의 없습니다. 글쎄, 사람들은 항상 현실에서 그렇게하고, 상황이 바뀌면 적응합니다. 그리고 그들이 합리적이라면 그들은 미래에 적응해야 할 변화가있을 수있는 것을 바탕으로 결정을 내릴 때를 알고 있습니다. 그래서 그것은 위험 관리 결정입니다. 프로그래머가 자유롭게 만들어야한다고 생각합니다. 사람들이 추상화로 프로그래밍하기를 원하고 구현 세부 사항과의 결혼을 원치 않는 감각이 없다면 결코 훌륭한 프로그래머가 될 수 없습니다.

... 아마도 OOP가 기반을 둔 기사 중 하나 일 것입니다.

실제로는 아니지만 토론에, 특히 당시 논문에서 설명한 첫 번째 기준을 사용하여 시스템을 분해하도록 훈련받은 실무자에게 추가되었습니다.

먼저 평가가 올바른지 알고 싶습니다. FP 패러다임과이 기사는 철학적으로 동의하지 않습니까?

또한 FP 프로그램의 모양에 대한 설명은 절차 나 기능을 사용하는 다른 것과 다를 바 없습니다.

데이터는 함수마다 전달되며 각 함수는 데이터를 밀접하게 인식하고 그 과정에서 "변경"합니다.

... "친밀감"부분을 제외하고 는 친밀감을 피하기 위해 추상 데이터에서 작동하는 기능을 가질 수 있고 종종 수행하기도합니다. 따라서, 당신은 그 "친밀감"을 어느 정도 제어 할 수 있으며, 숨기고 자하는 것에 대한 인터페이스 (예 : 기능)를 설정함으로써 원하는대로 조절할 수 있습니다.

따라서 우리가 함수형 프로그래밍을 사용하여 정보 숨기기에 대한 파르 나스 기준을 따를 수없는 이유는 없습니다. 두 번째 구현과 비슷한 장점을 가진 KWIC 지수를 구현하게되었습니다.

그들이 동의한다고 가정하면, 데이터 숨기기의 FP 구현이 무엇인지 알고 싶습니다. OOP에서 이것을 볼 수 있습니다. 수업 외부의 아무도 액세스 할 수없는 개인 필드를 가질 수 있습니다. FP에서 나에게 이것에 대한 명백한 비유는 없습니다.

데이터가 문제가되는 한 FP를 사용하여 데이터 추상화 및 데이터 유형 추상화를 구체화 할 수 있습니다. 이들 중 어느 것이 든 콘크리트 구조와 함수를 추상화로 사용하여 이러한 콘크리트 구조의 조작을 숨 깁니다.

편집하다

FP와 관련하여 "데이터 숨기기"가 그다지 유용하지 않다고 주장하는 주장이 점점 늘어나고 있습니다 (또는 OOP-ish (?)). SICP의 매우 간단하고 명확한 예를 여기에 표시하겠습니다.

시스템이 유리수로 작동해야한다고 가정하십시오. 그것들을 나타 내기 원하는 한 가지 방법은 분자와 분모의 두 쌍의 정수 또는 쌍의 목록입니다. 그러므로:

(define my-rat (cons 1 2)) ; here is my 1/2 

당신은 데이터 추상화를 무시하면, 가장 가능성이 당신이 사용하는 분자와 분모를 얻을 것이다 car및 cdr:

(... (car my-rat)) ; do something with the numerator

이 접근 방식에 따라, 유리수를 조작하는 시스템의 모든 부분은 유리수가 숫자임을 알게 cons됩니다 cons.리스트 연산자를 사용하여 유리수를 생성하고 추출 할 수 있습니다.

직면 할 수있는 한 가지 문제는 합리적인 수의 형식을 줄여야 할 때입니다. 전체 시스템에서 변경이 필요합니다. 또한 생성시 축소하기로 결정한 경우, 합리적인 용어 중 하나에 액세스 할 때 축소하는 것이 더 좋으며, 또 다른 전체 규모 변경이 발생합니다.

또 다른 문제는 가설 적으로 대체 표현이 선호되고 cons표현 을 포기하기로 결정한 경우 -다시 전체 스케일 변경입니다.

이러한 상황을 처리하기위한 모든 노력은 인터페이스 뒤의 합리적 표현을 숨기기 시작합니다. 결국 다음과 같이 끝날 수 있습니다.

• (make-rat <n> <d>)분자가 정수 <n>이고 분모가 정수인 유리수를 리턴합니다 <d>.

• (numer <x>)유리수의 분자를 돌려줍니다 <x>.

• (denom <x>)유리수의 분모를 돌려줍니다 <x>.

그리고 시스템은 더 이상 어떤 합리성이 만들어 졌는지 알지 못할 것이다. 이 때문입니다 cons, car그리고 cdr유리수의 본질이 아니라 make-rat, numer하고 denom 있습니다 . 물론 이것은 FP 시스템 일 수 있습니다. 따라서 "데이터 숨기기"(이 경우 데이터 추상화 또는 표현 및 콘크리트 구조를 캡슐화하려는 노력)는 OO, 함수 프로그래밍 또는 컨텍스트와 상관없이 관련 개념 및 널리 사용되는 기술로 제공됩니다. 도대체 무엇이.

그리고 요점은 ... (절차 적 추상화의 경우 디자인 결정이나 데이터 구조 또는 알고리즘을 숨기고 있는지 여부와 관계없이) "숨김"종류 나 캡슐화를 구분하려고 시도 할 수 있지만, 모든 이들의이 같은 주제를 가지고 : 그들은 파르 나스가 명시 적으로 만든 하나 개 이상의 지점에 의해 좌우된다. 그건:

• 변경 가능성 : 필요한 변경이 로컬로 이루어질 수 있는지 또는 시스템을 통해 확산되는지 여부
• 독립적 인 개발 : 시스템의 두 부분을 동시에 개발할 수있는 정도.
• 이해 : 시스템 중 하나를 이해하기 위해 필요한 시스템의 양.

위의 예는 SICP 서적에서 발췌 한 것이므로이 서적에서이 개념에 대한 전체 토론과 발표를 위해서는 2 장을 확인하는 것이 좋습니다 . 또한 FP와 관련하여 추상 데이터 유형에 익숙해지는 것이 좋습니다. 이로 인해 다른 문제가 발생합니다.

함수형 프로그래밍에 데이터 숨기기가 없다고 생각하는 것은 잘못입니다. 데이터를 숨기는 데 다른 접근 방식이 필요합니다. 함수형 프로그래밍에서 데이터를 숨기는 가장 일반적인 방법 중 하나는 함수를 인수로 취하는 다형성 함수를 사용하는 것입니다. 예를 들어이 기능

map :: (a -> b) -> [a] -> [b]
map _ [] = []
map f (x:xs) = f x : map f xs

데이터의 가장 바깥 쪽 구조 만 볼 수 있습니다 (예 : 목록 임). 목록에 포함 된 데이터에 대해서는 아무것도 볼 수 없으며 전달 된 단일 함수를 통해서만 데이터에 대해 작동 할 수 있습니다.

인수로 전달 된 함수는 목록에 포함 된 데이터 유형의 공용 메소드와 유사합니다. 데이터에서 작동하는 제한된 방법을 제공하지만 데이터 유형의 내부 작업을 노출하지 않습니다.

나는 여기서 사지를 파헤 치고 개념이 OO에서와 같이 FP와 관련이 없다고 말합니다.

tl; dr; 데이터 숨기기의 핵심은 책임을 유지해야하고 외부 지식이없는 데이터를 엉망으로 만드는 외부 행위자가없는 것입니다. FP에서 데이터는 표현식에 의해 생성되며, 이런 방식으로 게임의 규칙을 완전히 바꾸는 구성 가능한 계산만큼 변경 가능한 속성이 아니기 때문에 데이터를 엉망으로 만들 수 없습니다.

FP에 대한 나의 경험에서; 필연적으로 중요하지 않은, 나는 좋은 / 일반적인 데이터 모델링을 나타내는 것에서 OO와 뚜렷한 대조를 찾는 경향이 있습니다.

이와 대조적으로 OO에서는 일반적으로 데이터를 나타내는 것을 모델링합니다. 의무적 인 차 비유 :

OO

• AC 구현과 같이 자동차에 대한 세부 정보를 올바르게 숨기는 자동차 객체가 있습니다 (벨트 구동 또는 기압 구동? 소비자가 알 필요가 없으므로 숨겨야합니다).
• 이 자동차 객체에는 자동차에 대한 모든 사실과 자동차 작업 방법을 설명하는 많은 속성과 방법이 있습니다.
• 이 자동차 객체는 자동차의 특정 구현과 자동차의 구성 요소를 상호 교환 할 수 있도록하는 데이터 사실을 더 숨기는 자동차의 구성 요소 인 속성을 갖습니다.

여기서 주목해야 할 것은 OO 형식으로 사물을 모델링 할 때 사물을 데이터로 표현하는 것입니다. 속성이있는 개체가 있으며 이러한 속성 중 많은 속성이 더 많은 개체입니다. 여기에 몇 가지 방법이 있으며 해당 객체에 부착되어 있지만 실제로 수행하는 작업은 일반적으로 객체의 속성을 이런 식으로 트리거하는 것입니다. 다시 말하면 데이터 중심 모델링입니다. 즉, 소비자가 데이터를 이런 식으로 변경할 수 있도록 데이터의 모든 지점을 사용할 수 있도록 구성하는 데 중점을두고 데이터와 상호 작용하도록 데이터를 모델링합니다.

FP

• 행동을 설명 할 수있는 많은 계산이 있습니다.
• 이러한 행동 표현은 가속 / 감속을 갖는 자동차와 같이 자동차 행동이 서로 관련되는 방식으로 변환 될 수있는 방식으로 관련되어 있으며, 유사한 방식으로 서로 대립하는 두 가지 행동이 있습니다.

끊임없이 나에게 영향을 미치는 OO와 FP의 큰 차이점은 위에서 데이터를 모델링하는 방식에 대해 말한 것처럼입니다. 위에서 언급 한 OO에서는 데이터를 데이터로 모델링하고, FP에서는 데이터를 계산, 표현식, 알고리즘으로 모델링합니다. 사실보다 데이터의 활동을 모델링하는 것에 관한 것입니다. 수학의 기본 데이터 모델링에 대해 생각해보십시오. 데이터를 생성 할 수있는 방정식을 얻는 것에 관한 것입니다. 데이터를 생성하는 활동으로 데이터를 모델링하는 OO와는 달리 모델링은 데이터를 나타내는 방법을 제시합니다. 즉 많은 FP와 OO의 차이의.

기초 FP 언어 중 하나 인 LISP는 아주 적은 양의 원시 데이터 유형과 함께 살았습니다. 접근 방식은 시스템의 동작을 생성하고 표현하는 계산만큼 복잡한 데이터 표현을 모델링하는 것이 아니기 때문에 효과적입니다.

FP에서 코드를 작성하기 시작하면 무언가를 수행하는 코드를 작성하는 것으로 시작합니다. OO에서 코드 작성을 시작할 때 무언가를 설명하는 모델을 작성하는 것으로 시작합니다. 일을하는 것은 표현에 의해 FP에 숨겨지고, 일을하는 것은 데이터로 기술되어 OO에 노출되며,이 데이터를 숨기면 노출이 제한됩니다.

당면한 질문으로 돌아가서, FP는 데이터 숨기기에 대해 무엇을 말하고, 그것을 감추거나 동의하지 않습니까?

OO에서 데이터는 방해가되지 않도록 숨겨야 할 프로그램의 내장과 중요한 부분입니다. FP에서 시스템의 내장과 지식은 시스템을 표현하는 알고리즘과 계산에 숨겨져 있습니다. 이들은 정의상 다소 불변이며 계산 표현식을 변경하는 유일한 방법은 매크로와 같은 것입니다. 그러나 심지어 돌연변이 정의는 더 이상 혼잡 할 수없는 표현식 자체입니다.

여기에는 약간의 역설이 있습니다. 함수형 프로그래밍은 함수에 초점을 맞추고 기본 데이터 형식에서 직접 작동하는 함수를 자주 사용 하지만 개체 지향 프로그래밍보다 더 많은 데이터 숨기기 기능을 제공합니다.

이것은 어떻게됩니까? 기본 데이터, 아마도 컬렉션을 숨기는 멋진 OO 인터페이스를 생각해보십시오 (거의 유비쿼터스를 선택하려고합니다). 컬렉션이 IEnumerable을 구현한다는 것을 알고 있다면 컬렉션의 기본 개체 유형이나 컬렉션을 구현하는 개체 유형을 알 필요가 없습니다. 데이터가 숨겨져 있습니다.

함수형 프로그래밍에서는 IEnumerable 인터페이스와 효과적으로 작동하지만 기본 데이터 형식 (또는 모든 데이터 형식)에서 작동하는 함수를 작성할 수 있습니다. 그러나 형식이 IEnumerable 메서드를 구현하지 않으면 어떻게 될까요? 여기에 핵심 이 있습니다. 필요한 "인터페이스"조각을 형성하는 "메소드"를 함수에 전달 된 매개 변수로 항상 가질 수 있습니다. 또는 함수를 데이터와 함께 배치하고 OO와 같은 방식으로 작업을 수행 할 수 있습니다.

어느 쪽이든 OO에서보다 데이터 숨기기가 적지 않습니다. 모든 유형에서 명확하게 작동하는 내 일반 함수 는 해당 유형의 데이터에 액세스하지 않습니다. 일반 함수에 매개 변수로 전달 된 함수 내에서 발생하지만 일반 함수는 절대로 해당 함수 내부에서 데이터를 보지 않습니다.

따라서 1 포인트까지 FP와 기사가 실제로 동의하지 않는다고 생각합니다. 데이터를 숨기지 않는 FP의 특성화가 올바른 것으로 생각하지 않습니다. 저자가 FP에서 선호하는 디자인을 구현할 수있을 것입니다.

포인트 4 (2와 3은 포인트 1에 대해 말한 것을 감안할 때 대답이 의미가 없습니다)까지는 다양합니다. 또한 OO 언어로 다양하며 많은 개인 분야에서 언어에 의해 시행되는 것이 아니라 관례에 따라 비공개입니다.

첫째,이 위대한 기사에 대한 링크 덕분에, 나는 지금까지 이것을 알지 못했고, 지난 몇 년 동안 커뮤니티의 다른 소프트웨어 디자이너들과 논의한 것들에 대한 훌륭한 정보를 얻었습니다. 그것에 대한 내 의견은 다음과 같습니다.

먼저 평가가 올바른지 알고 싶습니다. FP 패러다임과이 기사는 철학적으로 동의하지 않습니까?

FP 디자인은 데이터 흐름에 매우 중점을 둡니다 (IMHO는 기사가 암시하는 것처럼 나쁘지 않습니다). 이것이 완전한 "불일치"라면 논쟁의 여지가 있습니다.

그들이 동의하지 않는다고 가정 할 때, FP는 데이터 숨기기 부족에 대해 어떻게 "보상"합니까? 아마도 그들은 데이터 숨기기를 희생하지만 X, Y 및 Z를 얻습니다. X, Y 및 Z가 데이터 숨기기보다 더 유익한 이유를 알고 싶습니다.

IMHO는 보상하지 않습니다. 아래를 참조하십시오.

또는 그들이 동의하지 않는다고 가정하면, 아마도 FP는 데이터 숨기기가 나쁘다고 생각할 것입니다. 그렇다면 왜 데이터 숨기기가 나쁘다고 생각합니까?

나는 대부분의 FP 사용자 나 디자이너가 이런 식으로 느끼거나 생각한다고 생각하지 않습니다. 아래를 참조하십시오.

그들이 동의한다고 가정하면, 데이터 숨기기의 FP 구현이 무엇인지 알고 싶습니다. OOP에서 이것을 볼 수 있습니다. 수업 외부의 아무도 액세스 할 수없는 개인 필드를 가질 수 있습니다. FP에서 나에게 이것에 대한 명백한 비유는 없습니다.

요점은 아마도 OOP가 작동하지 않는다고 생각하는 많은 OOP 시스템이 작동하지 않는 방식으로 구현 된 것을 보았을 것입니다. IMHO OOP와 FP는 대부분 직교 개념이며, 기능적 OO 시스템을 완벽하게 구축 할 수있어 질문에 대한 명확한 답변을 얻을 수 있습니다. FP의 고전적인 "객체"구현은 클로저 를 사용하여 수행되며 , 기능 시스템에서 객체를 사용하려면 불변의 디자인이 핵심입니다.

따라서 더 큰 시스템을 만들기 위해 IMHO를 사용하면 "FP 경로"를 떠나지 않고이 기사의 "모듈화 2"에 설명 된대로 OO 개념을 사용하여 모듈, 클래스 및 개체를 만들 수 있습니다. 자주 사용하는 FP 언어의 모듈 개념을 사용하고 모든 객체를 변경할 수 없으며 "두 세계의 최고"를 사용합니다.

TL; DR : 아니오

FP 패러다임과이 기사는 철학적으로 동의하지 않습니까?

아닙니다. 기능적 프로그래밍은 "제어 흐름을 설명하지 않고 계산의 논리를 표현하는 컴퓨터 프로그램의 구조와 요소를 구축하는 스타일"인 선언적입니다 . 순서도를 따르는 것이 아니라 흐름을 자체적으로 발생시키는 규칙을 만드는 것과 비슷합니다.

절차 적 프로그래밍은 기능적 프로그래밍보다 플로우 차트 인코딩에 훨씬 가깝습니다. 플로우 차트의 플로우가 설명하는 것과 똑같이 발생하는 변환을 따르고 해당 변환을 순서대로 실행되는 프로 시저로 인 코드합니다.

절차 적 언어는 공유 상태를 암시 적으로 변경할 수있는 일련의 명령형 명령으로 프로그램의 실행을 모델링하는 반면, 함수형 프로그래밍 언어는 인수 및 반환 값의 관점에서만 서로 의존하는 복잡한 식의 평가로 실행을 모델링합니다. 이러한 이유로, 기능적 프로그램은보다 자유로운 코드 실행 순서를 가질 수 있으며, 언어는 프로그램의 다양한 부분이 실행되는 순서를 거의 제어 할 수 없습니다. 예를 들어, Scheme에서 프로 시저 호출에 대한 인수는 임의의 순서로 실행됩니다.

데이터 숨기기

• 함수형 프로그래밍에는 자체 데이터 숨기기 방법 (예 : think closures)이 있습니다. 즉, 클로저에 캡슐화되어 데이터가 숨겨져 있습니다. 클로저에만 데이터에 대한 참조가 있으며 클로저 외부에서이를 참조 할 수 없으므로 필드가 더 이상 개인 데이터로 닫히기가 어렵습니다.
• 데이터 숨기기의 이유 중 하나는 변경 데이터를 숨겨 프로그래밍 인터페이스를 안정화하기위한 것입니다. 함수형 프로그래밍에는 데이터를 변경하지 않으므로 많은 데이터 숨기기가 필요하지 않습니다.