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?
12
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.
2