Отношение между объектом

Question

В течение нескольких недель я думал об отношениях между объектами - не особенно объектами ООП. Например, в C++ мы привыкли представлять это с помощью наложения указателей или контейнеров указателей в структуре, которой требуется доступ к другому объекту. Если объект A должен иметь доступ к B, это не редкость, чтобы найти B *pB в A,

Но я больше не программист на C++, я пишу программы на функциональных языках, особенно на Haskell, который является чисто функциональным языком. Можно использовать указатели, ссылки или что-то в этом роде, но я чувствую себя странно с этим, как "делать это не-Хаскель".

Затем я немного глубже подумал обо всех этих вещах, связанных с отношениями, и пришел к выводу:

"Почему мы даже представляем такое отношение по слоям?

Я читал, что некоторые люди уже думали об этом ( здесь). С моей точки зрения, представление отношений с помощью явных графических изображений намного лучше, поскольку оно позволяет нам сосредоточиться на ядре нашего типа, а выражать отношения позже - с помощью комбинаторов (немного как в SQL).

Под ядром я подразумеваю, что когда мы определяем Aмы ожидаем определить, что A состоит не из того, от чего это зависит. Например, в видеоигре, если у нас есть тип CharacterЗаконно говорить о Trait, Skill или что-то в этом роде, но это если мы говорим о Weapon или же Items? Я больше не уверен в этом. Затем:

data Character = {
    chSkills :: [Skill]
  , chTraits :: [Traits]
  , chName   :: String
  , chWeapon :: IORef Weapon -- or STRef, or whatever
  , chItems  :: IORef [Item] -- ditto
  }

звучит действительно неправильно с точки зрения дизайна для меня. Я бы предпочел что-то вроде:

data Character = {
    chSkills :: [Skill]
  , chTraits :: [Traits]
  , chName   :: String
  }

-- link our character to a Weapon using a Graph Character Weapon
-- link our character to Items using a Graph Character [Item] or that kind of stuff

Кроме того, когда приходит день добавлять новые функции, мы можем просто создавать новые типы, новые графики и ссылки. В первом дизайне нам пришлось бы сломать Character введите, или используйте какую-то работу вокруг, чтобы расширить его.

Что вы думаете об этой идее? Как вы думаете, что лучше всего решать с такими проблемами в Haskell, чисто функциональном языке?