Per alcune settimane ho pensato alla relazione tra gli oggetti - non in particolare gli oggetti di OOP. Ad esempio in C ++ , siamo abituati a rappresentarlo mediante la stratificazione di puntatori o contenitori di puntatori nella struttura che richiede un accesso all'altro oggetto. Se un oggetto A deve avere un accesso a B , non è raro trovare un B *pB in A .
Ma non sono più un programmatore C ++ , scrivo programmi usando linguaggi funzionali, e soprattutto in Haskell , che è un puro linguaggio funzionale. È possibile usare puntatori, riferimenti o quel tipo di cose, ma mi sento strano, come "farlo in modo non Haskell".
Poi ho pensato un po 'più a fondo a tutte quelle relazioni e sono arrivato al punto:
“Why do we even represent such relation by layering?
Ho letto alcune persone che ci avevano già pensato ( qui ). Dal mio punto di vista, rappresentare le relazioni attraverso grafici espliciti è meglio perché ci consente di concentrarci sul core del nostro tipo, e di esprimere relazioni in seguito attraverso i combinatori (un po 'come SQL fa).
Per core intendo che quando definiamo A , ci aspettiamo di definire cosa A è fatto di , non ciò che dipende da . Ad esempio, in un videogioco, se abbiamo un tipo Character , è legittimo parlare di Trait , Skill o di quel tipo di cose, ma è se parliamo di Weapon o Items ? Non sono più così sicuro. Poi:
data Character = {
chSkills :: [Skill]
, chTraits :: [Traits]
, chName :: String
, chWeapon :: IORef Weapon -- or STRef, or whatever
, chItems :: IORef [Item] -- ditto
}
mi sembra davvero sbagliato in termini di design. Preferirei preferire qualcosa come:
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
Inoltre, quando arriva un giorno per aggiungere nuove funzionalità, possiamo semplicemente creare nuovi tipi, nuovi grafici e link. Nel primo progetto, dovremmo rompere il tipo Character , o usare un qualche tipo di
lavorare per estenderlo.
Cosa ne pensi di questa idea? Quale pensi che sia meglio affrontare questo tipo di problemi in Haskell , un puro linguaggio funzionale?