모나드가 상속 계층에 대한 실행 가능한 대안일까요?

먼저 monoid를 설명하는 이와 같은 모나드에 대해 언어에 구애받지 않는 설명 을 사용하겠습니다 .

모노 이드는 파라미터로서 몇 가지 유형을 가지고 동일한 유형을 반환하는 함수의 (대략) 세트이다.

모나드 테이크 함수 (약) 세트이다 래퍼 인자로 타입과 동일한 타입 래퍼를 반환한다.

그것들은 정의가 아니라 설명입니다. 그 설명을 자유롭게 공격하십시오!

따라서 OO 언어에서 모나드는 다음과 같은 연산 구성을 허용합니다.

Flier<Duck> m = new Flier<Duck>(duck).takeOff().flyAround().land()

모나드는 포함 된 클래스가 아닌 해당 작업의 의미를 정의하고 제어합니다.

전통적으로 OO 언어에서는 클래스 계층 구조와 상속을 사용하여 이러한 의미를 제공합니다. 그래서 우리는 거라고 Bird방법과 클래스를 takeOff(), flyAround()그리고 land(), 오리는 사람들을 상속합니다.

그러나 우리는 날지 못하는 새들 때문에 어려움을 겪습니다 penguin.takeOff(). 실패 하기 때문 입니다. 예외 처리 및 처리에 의지해야합니다.

또한 펭귄이 a라고 말하면 Bird계층 구조가 여러 개인 경우와 같이 다중 상속에 문제가 발생 Swimmer합니다.

본질적으로 우리는 클래스를 범주에 넣고 (범주 이론 녀석에게 사과와 함께) 개별 클래스가 아닌 범주별로 의미를 정의하려고합니다. 그러나 모나드는 계층 구조보다 훨씬 명확한 메커니즘처럼 보입니다.

이 경우 Flier<T>위의 예와 같은 모나드 가 있습니다 .

Flier<Duck> m = new Flier<Duck>(duck).takeOff().flyAround().land()

... 우리는 결코 인스턴스화하지 않을 것 Flier<Penguin>입니다. 우리는 정적 타이핑을 사용하여 마커 인터페이스와 함께 발생하지 않도록 할 수도 있습니다. 또는 런타임 기능 검사로 구제 할 수 있습니다. 그러나 실제로 프로그래머는 절대로 펭귄을 Flier에 넣지 말아야합니다. 같은 의미에서 결코 0으로 나누지 않아야합니다.

또한 더 일반적으로 적용됩니다. 전단지는 새일 필요는 없습니다. 예를 들어 Flier<Pterodactyl>, 또는 Flier<Squirrel>개별 유형의 의미를 변경하지 않은 경우.

유형 계층 구조가 아닌 컨테이너의 구성 가능한 함수로 의미를 분류하면 특정 계층 구조에 맞는 "종류, 유형, 종류"가 아닌 클래스의 오래된 문제를 해결합니다. 또한 클래스 Flier<Duck>뿐만 아니라 여러 의미를 쉽고 명확하게 허용합니다 Swimmer<Duck>. 클래스 계층과 동작을 분류하여 임피던스 불일치로 어려움을 겪고있는 것 같습니다. 모나드는 그것을 우아하게 처리합니다.

그래서 제 질문은 상속보다 구성을 선호하는 것과 같은 방식으로 상속보다 모나드를 선호하는 것이 합리적입니까?

(BTW 이것이 여기에 있는지 아니면 Comp Sci에 있는지 확실하지 않지만 실제 모델링 문제처럼 보입니다. 그러나 아마도 더 좋을 것입니다.)

짧은 대답은 no입니다 . 모나드는 상속 계층 구조 (하위 유형 다형성이라고도 함)의 대안이 아닙니다. 모나드가 사용 하는 파라 메트릭 다형성을 설명하는 것 같지만 그렇게하는 것은 아닙니다.

내가 이해하는 한 모나드는 본질적으로 상속과 관련이 없습니다. 나는 두 가지가 거의 직교라고 말하고 싶습니다. 그것들은 다른 문제를 해결하기위한 것입니다.

1. 적어도 두 가지 의미에서 시너지 효과를 발휘할 수 있습니다.
   • Haskell의 많은 유형 클래스를 다루는 Typeclassopedia를 확인하십시오 . 그들 사이에는 상속과 같은 관계가 있음을 알 수 있습니다. 예를 들어 Monad는 Applicative의 자손이며 Functor의 자손입니다.
   • Monads의 인스턴스 인 데이터 유형은 클래스 계층에 참여할 수 있습니다. Monad는 인터페이스와 비슷합니다. 주어진 유형에 대해 구현하면 데이터 유형에 대한 정보가 있지만 전부는 아닙니다.
2. 하나를 사용하여 다른 하나를 시도하는 것은 어렵고 추악합니다.

마지막으로, 이것은 귀하의 질문에 대한 접선이지만 모나드에는 구성 할 수있는 매우 강력한 방법이 있다는 것을 배우고 싶을 것입니다. 자세한 내용은 모나드 변압기를 읽어보십시오. 그러나, 우리는 (나보다 100 만배 더 똑똑한 사람들이 모나드를 구성하는 훌륭한 방법을 찾지 못했고, 일부 모나드가 임의로 구성하지 않는 것처럼 보이기 때문에) 이것은 여전히 ​​활발한 연구 영역입니다.

이제 귀하의 질문을 nit-pick하기 위해 (죄송합니다. 이것이 도움이되고 나쁘게 느끼지 않기를 바랍니다)

1. 모나드는 컨테이너 유형을 매개 변수로 사용하고 동일한 컨테이너 유형을 리턴하는 함수 세트입니다.

   아니, 이것은 이다 Monad하스켈 : 파라미터 화 된 형태 m a의 구현 return :: a -> m a및 (>>=) :: m a -> (a -> m b) -> m b다음과 같은 법칙을 만족 :

   return a >>= k  ==  k a
   m >>= return  ==  m
   m >>= (\x -> k x >>= h)  ==  (m >>= k) >>= h
   

   컨테이너 ( (->) b) 가 아닌 Monad의 일부 인스턴스 Set가 있으며 형식 클래스 제약으로 인해 Monad ()의 인스턴스가 아니거나 만들 수없는 컨테이너가 있습니다 ( ). "컨테이너"직관은 좋지 않습니다. 더 많은 예를 보려면 이것을 참조하십시오 .

2. 따라서 OO 언어에서 모나드는 다음과 같은 연산 구성을 허용합니다.

     Flier<Duck> m = new Flier<Duck>(duck).takeOff().flyAround().land()
   

   아뇨, 전혀 아닙니다. 이 예에는 Monad가 필요하지 않습니다. 입력 및 출력 유형이 일치하는 기능 만 있으면됩니다. 함수 응용 프로그램이라는 것을 강조하는 또 다른 방법은 다음과 같습니다.

   Flier<Duck> m = land(flyAround(takeOff(new Flier<Duck>(duck))));
   

   나는 이것이 "유창한 인터페이스"또는 "메소드 체인"이라고 알려진 패턴이라고 생각합니다 (그러나 확실하지는 않습니다).

3. 모나드는 포함 된 클래스가 아닌 해당 작업의 의미를 정의하고 제어합니다.

   모나드이기도 한 데이터 유형은 모나드와 관련이없는 작업을 가질 수 있습니다. 다음 []은 모나드와 관련이없는 세 가지 함수로 구성된 Haskell 예제입니다 . []"작업의 의미를 정의하고 제어합니다"및 "포함 된 클래스"는 모나드를 만들기에는 충분하지 않습니다.

   \predicate -> length . filter predicate . reverse
   

4. 클래스 계층 구조를 사용하여 사물을 모델링하는 데 문제가 있음을 올바르게 알고 있습니다. 그러나 귀하의 예는 모나드가 다음을 수행 할 수 있다는 증거를 제시하지 않습니다.

   • 상속이 잘되는 일을 잘해라
   • 상속이 나쁜 물건을 잘해라

그래서 제 질문은 상속보다 구성을 선호하는 것과 같은 방식으로 상속보다 모나드를 선호하는 것이 합리적입니까?

비 OO 언어에서는 그렇습니다. 더 전통적인 OO 언어에서는 아니오라고 말할 것입니다.

문제는 대부분의 언어는 당신이 할 수없는 의미 유형의 전문화를 필요가 없다는 것입니다 Flier<Squirrel>및 Flier<Bird>다른 구현이있다. 당신은 static Flier Flier::Create(Squirrel)(그리고 각 유형마다 과부하) 같은 것을해야합니다 . 이는 새로운 동물을 추가 할 때마다이 유형을 수정해야하며,이를 위해 약간의 코드를 복제해야 할 수도 있습니다.

아, 그리고 몇몇 언어 (예 : C #) public class Flier<T> : T {}는 불법입니다. 심지어 빌드되지 않습니다. 모든 OO 프로그래머가 아니지만 대부분은 Flier<Bird>여전히 Bird.