Relation between objects

Question

For a few weeks I’ve been thinking about relation between objects – not especially OOP’s objects. For instance in C++, we’re used to representing that by layering pointers or container of pointers in the structure that needs an access to the other object. If an object A needs to have an access to B, it’s not uncommon to find a B *pB in A.

But I’m not a C++ programmer anymore, I write programs using functional languages, and more especially in Haskell, which is a pure functional language. It’s possible to use pointers, references or that kind of stuff, but I feel strange with that, like "doing it the non-Haskell way".

Then I thought a bit deeper about all that relation stuff and came to the point:

"Why do we even represent such relation by layering?

I read some folks already thought about that (here). In my point of view, representing relations through explicit graphes is way better since it enables us to focus on the core of our type, and express relations later through combinators (a bit like SQL does).

By core I mean that when we define A, we expect to define what A is made of, not what it depends on. For instance, in a video game, if we have a type Character, it’s legit to talk about Trait, Skill or that kind of stuff, but is it if we talk about Weapon or Items? I’m not so sure anymore. Then:

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

sounds really wrong in term of design to me. I’d rather prefer something like:

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

Furthermore, when a day comes to add new features, we can just create new types, new graphs and link. In the first design, we’d have to break the Character type, or use some kind of work around to extend it.

What do you think about that idea? What do you think is best to deal with that kind of issues in Haskell, a pure functional language?

• Doval: Polling for opinions is not allowed here. You should rephrase the question to something along the lines of "are there any drawbacks to this approach?" instead of "what do you think of this?" or "what is the best way to...?" For whatever it's worth, it doesn't make sense to ask why things are done a certain way in C++ as opposed to the way it's done in functional languages, because C++ lacks garbage collection, anything analogous to type classes (unless you use templates, which opens a really big can of worms), and many other features that facilitate functional programming.
• Doval: One thing worth nothing is that in your approach, it's not possible to tell using the type system whether a Character should be able to hold weapons. When you have a map from Characters to Weapons and a character is absent from the map, does that mean the character doesn't currently hold a weapon, or that the character can't hold weapons at all? Moreover, you'd be doing unnecessary lookups because you don't know a priori whether a Character can hold a weapon or not.
• bheklilr: @Doval If characters being unable to hold weapons was a feature in your game, wouldn't it make sense to then give the character record a canHoldWeapons :: Bool flag, which lets you know immediately if it can hold weapons, and then if your character isn't in the graph you can say that the character isn't currently holding weapons. Make giveCharacterWeapon :: WeaponGraph -> Character -> Weapon -> WeaponGraph just act like id if that flag is False for the character provided, or use Maybe to represent failure.
• Jimmy Hoffa: I like this and frankly think what you're designing fits an applicative style very well - which I tend to find common when looking at doing OO modeling problems in Haskell. Applicatives allow you to nicely and fluently compose CRUD style behaviours, so the idea that you would model bits independently, then have some applicative implementations that let you compose those types together with operations being slipped inbetween the compositions for things like validation, persistence, reactive event firing etc. This fits very much with what you suggest there. Graphs work great with applicatives.
• bheklilr: @Doval Specifically with record style data types, if you have multiple constructors the following code is perfectly legal and does not emit warnings with -Wall on GHC: data Foo = Foo { foo :: Int } | Bar { bar :: String }. It then type checks to call foo (Bar "") or bar (Foo 0), but both will raise exceptions. If you're using positional style data constructors then there isn't a problem because the compiler doesn't generate the accessors for you, but you don't get the convenience of the record types for large structures and it takes more boilerplate to use libraries like lens.

Answer 1

You have actually answered your own question you just don't know it yet. The question you're asking is not about Haskell but about programming in general. You're actually asking yourself very good questions (kudos).

My approach to the problem you have at hand divides basically in two main aspects: the domain model design and trade-offs.

Let me explain.

Domain Model Design: This is how you decide to organize the core model of your application. I can see you're already doing that by thinking of Characters, Weapons and so on. Plus you need to define the relations between them. Your approach of defining objects by what they are instead of what they depend on is totally valid. Be careful though because it's not a silver bullet for every decision regarding your design.

You're definitely doing the right thing by thinking of this in advance but at some point you need to stop thinking and start writing some code. You'll see then if your early decisions were the right ones or not. Most likely not since you don't have yet full knowledge of your application. Then don't be afraid of refactoring when you realize certain decisions are becoming a problem not a solution. It's important to write code as you think of those decisions so you can validate them and avoid having to rewrite the entire thing.

There are several good principles you can follow, just google for "software principles" and you'll find a bunch of them.

Trade-offs: Everything is a trade-off. On one hand having too many dependencies is bad however you'll have to deal with extra complexity of managing dependencies somewhere else rather than in your domain objects. There's no right decision. If you have a gut feeling go for it. You'll learn a lot by taking that path and seeing the result.

Like I said, you're asking the right questions and that's the most important thing. Personally I agree with your reasoning but it looks you've already put too much time thinking about it. Just stop being afraid of making a mistake and make mistakes. They are really valuable and you can always refactor your code whenever you see fit.

• phaazon: Thank you for your answer. Since I posted that, I took a lot of paths. I tried AST, bound AST, free monads, now I’m trying to represent the whole thing through typeclasses. Indeed, there’s no absolute solution. I just feel the need to challenge the common way of doing relationship, which is to me far from being robust and flexible.
• Alex: @phaazon That's great and I wish more developers had a similar approach. Experimenting is the best learning tool. Good luck with your project.