Чи монади є життєздатною (можливо, кращою) альтернативою ієрархіям спадкування?

Я буду використовувати мовно-агностичний опис монад на кшталт цього, спочатку опишу моноїди:

Моноїд це (приблизно) набір функцій , які приймають певний тип в якості параметра і повертають один і той же тип.

Монада є (приблизно) набір функцій , які приймають обгортки типу в якості параметра і повертає один і той же тип обгортки.

Зауважте, що це описи, а не визначення. Не соромтеся атакувати цей опис!

Так, мовою ОО, монада дозволяє виконувати такі операції, як:

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

Зауважте, що монада визначає та керує семантикою цих операцій, а не класом, що міститься.

Традиційно в мові ОО ми використовували ієрархію класів і успадкування для надання цієї семантики. Таким чином , ми будемо мати Birdклас з методами takeOff(), flyAround()і land(), і качка успадкує ті.

Але тоді ми потрапляємо в біду з нелітаючими птахами, бо penguin.takeOff()не вдається. Ми маємо вдатися до викидів та поводження з винятками.

Крім того, як тільки ми кажемо, що Пінгвін - це Bird, ми стикаємося з проблемами багаторазового успадкування, наприклад, якщо ми також маємо ієрархію Swimmer.

По суті ми намагаємось класти класи в категорії (з вибаченнями для хлопців із Теорії категорій) та визначати семантику за категоріями, а не в окремих класах. Але монади здаються набагато зрозумілішим механізмом для цього, ніж ієрархії.

Тож у цьому випадку у нас буде Flier<T>монада, як у наведеному вище прикладі:

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

... і ми ніколи не створимо це Flier<Penguin>. Ми навіть можемо використовувати статичне введення тексту, щоб не допустити цього, можливо, із інтерфейсом маркера. Або перевірка можливостей виконання, щоб отримати заставу. Але дійсно, програміст ніколи не повинен ставити Пінгвіна в Flier, в тому ж сенсі вони ніколи не повинні ділитися на нуль.

Крім того, він більш загальноприйнятний. Летчик не повинен бути птахом. Наприклад Flier<Pterodactyl>, або Flier<Squirrel>, не змінюючи семантики цих окремих типів.

Після того, як ми класифікуємо семантику за складовими функціями на контейнері - замість ієрархій типів - вона вирішує старі проблеми з класами, які "роблять, роблять, не" вписуються в певну ієрархію. Це також легко і чітко дозволяє проводити кілька семантик для класу, як Flier<Duck>і Swimmer<Duck>. Схоже, ми боролися з невідповідністю імпедансу, класифікуючи поведінку за ієрархіями класів. Монади справляються з цим елегантно.

Отже, моє запитання полягає в тому, що ми також віддаємо перевагу складу над спадщиною, чи має сенс віддавати перевагу монадам над спадщиною?

(До речі, я не був впевнений, чи має це бути тут, чи в Comp Sci, але це здається більше проблемою практичного моделювання. Але, можливо, там краще.)

Коротка відповідь - ні , монади не є альтернативою ієрархії спадкування (також відомий як політип поліморфізму підтипу). Здається, ви описуєте параметричний поліморфізм , яким користуються монади, але це не єдине, що потрібно зробити.

Наскільки я їх розумію, монади по суті не мають нічого спільного з спадщиною. Я б сказав, що дві речі є більш-менш ортогональними: вони призначені для вирішення різних проблем, і так:

1. Їх можна використовувати синергетично принаймні у двох сенсах:
   • ознайомтеся з Typeclassopedia , який охоплює багато класів типів Haskell. Ви помітите, що між ними є спадкові відносини. Наприклад, Монада походить від Applicative, який сам походить від Functor.
   • типи даних, які є екземплярами Monads, можуть брати участь у ієрархіях класів. Пам'ятайте, Monad більше схожий на інтерфейс - реалізація його для заданого типу розповідає вам деякі речі про тип даних, але не все.
2. Намагатися використовувати одне для іншого, буде важко і негарно.

Нарешті, хоча це дотичне для вашого питання, можливо, вам буде цікаво дізнатись, що монадам є неймовірно потужні способи складання; читайте про трансформатори монади, щоб дізнатися більше. Однак це все ще активна область досліджень, тому що ми (маючи на увазі, люди на 100000 разів розумніші за мене) не знайшли чудових способів складання монад, і, схоже, деякі монади не складають довільно.

Тепер, щоб вибрати своє запитання (вибачте, я маю на увазі, щоб це було корисно, а не для того, щоб почувати себе погано): Я відчуваю, що існує багато сумнівних приміщень, на які я спробую пролити трохи світла.

1. Монада - це набір функцій, який приймає тип контейнера як параметр і повертає той самий тип контейнера.

   Ні, це є Monadв Haskell: параметризрвані типу 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
   

   Є деякі екземпляри Monad, які не є контейнерами ( (->) b), а є деякі контейнери, які не є (і не можуть бути зроблені) екземплярами Monad ( Setчерез обмеження класу типів). Так що "контейнерна" інтуїція погана. Дивіться це для додаткових прикладів.

2. Так, мовою ОО, монада дозволяє виконувати такі операції, як:

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

   Ні, зовсім ні. Цей приклад не вимагає монади. Все, що потрібно, - це функції, що відповідають типам вводу та виводу. Ось ще один спосіб його написання, який підкреслює, що це просто функціональна програма:

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

   Я вважаю, що це схема, відома як "вільний інтерфейс" або "ланцюжок методів" (але я не впевнений).

3. Зауважте, що монада визначає та керує семантикою цих операцій, а не класом, що міститься.

   Типи даних, які також є монадами, можуть (і майже завжди це робити!) Мають операції, не пов'язані з монадами. Ось приклад Haskell, що складається з трьох функцій, []які не мають нічого спільного з монадами: []"визначає та контролює семантику операції", а "міститься клас" не робить, але цього недостатньо для створення монади:

   \predicate -> length . filter predicate . reverse
   

4. Ви правильно зазначили, що існують проблеми із використанням ієрархій класів для моделювання речей. Однак у ваших прикладах немає жодних доказів того, що монади можуть:

   • Робіть хорошу роботу в тих речах, в яких є спадщина
   • Робіть гарну роботу в тих речах, на які спадщина погана

Отже, моє запитання полягає в тому, що ми також віддаємо перевагу складу над спадщиною, чи має сенс віддавати перевагу монадам над спадщиною?

Так, мовами, що не належать до ОО, так. У більш традиційних мовах ОО я б сказав «ні».

Проблема полягає в тому, що більшість мов не мають спеціалізації типів, тобто ви не можете робити Flier<Squirrel>та Flier<Bird>мати різні реалізації. Ви повинні зробити щось на кшталт static Flier Flier::Create(Squirrel)(а потім перевантажувати для кожного типу). Що в свою чергу означає, що вам потрібно змінювати цей тип кожного разу, коли ви додаєте нову тварину, і, ймовірно, дублюєте зовсім небагато коду, щоб вона працювала.

Ну, і в не декількох мовах (наприклад, C #) public class Flier<T> : T {}є незаконним. Він навіть не будуватиметься. Більшість, якби не всі програмісти OO очікували, що Flier<Bird>вони все ще будуть Bird.