One other random question, given that we're here. For computer games, one of the
slight troubles with the OO method is the fact that many objects are unique (the player say, or a particular boss); sometimes it feels like overkill to have a class that there's only ever going to be one instance of any particular class. It is just a matter of defining a class, then declaring an instance of it, but still. One one occasion, instead of having a virtual 'entity' class with virtual 'move' and 'collide' functions, I just had the move and collide functions be member variables. I found this approach to be quite liberating at the time when i was using it.
The code looked like this:
levelEntities :: [Entity]
levelEntities=[
Entity{pos=(1,1), movement=stayStill, collide=playercollide},
Entity{pos=(5,5), movement=moveUpDown, collide=unstdcollide },
Entity{pos=(5,6), movement=moveLeftRight, collide=unstdcollide },
Entity{pos=(5,7), movement=moveClockwise, collide=stdcollide },
Entity{pos=(5,8), movement=moveLeftRight, collide=unstdcollide },
Entity{pos=(5,9), movement=moveLeftRight, collide=unstdcollide }
]
where the movement and collision functions were defined elsewhere. (I guess for larger projects you could use lambda-expressions or some other sort of in-line declarations to keep things grouped together).
I'm inclined to think, on the basis of this, that games where every object is more-or-less unique in its behaviour (where the OO inheritance tree wouldn't be more than one level deep, say) are better dealt with in other ways.
I've seen this sort of method talked about in effective C++, I think; I don't know if it has a name as such, though.
Developer
