OOP: Can an entity object know what room it's in?

Started by
5 comments, last by Zole 21 years, 7 months ago
I''ve heard some vague messages on this topic, so I thought I''d solicit some thoughts. I''ve been told that objects shouldn''t "know" anything about the objects that logically "contain" them - for example, in my game engine, Entity objects shouldn''t have a pointer to the Room objects they''re located in. This can be awkward at times, and I''ve just run into a situation where it would be far less awkward just to tell each Entity what room it''s in (give it a pointer to the room). Assuming this pointer is kept accurate and isn''t used for anything dangerous, like deleting the room, is this an acceptable approach?
Advertisement
There really is no right and wrong way to do something as far as design goes, just ways that work better than others. The OOP purists may say otherwise, but if it works for you, go ahead and do it if you can't find another way around it.

[edited by - Machaira on September 1, 2002 1:34:17 AM]

Former Microsoft XNA and Xbox MVP | Check out my blog for random ramblings on game development

Well, here are a few ideas that are still OOP true, but may work.

So you have an object which contains other objects. One idea is to make a method on the container which dispatches to the objects which it contains, but passes a pointer to itself to the objects, thus telling it who contains it.

I suppose the big question is how connected are the children/parent of this group? If the children are moved about often, and keeping a backpointer would become a hassle, then I would look for a way that didn''t use it. However, if this hierarchy is semi-permenant, it should be fine to keep a backpointer.
Instead of actually putting "rooms in entities" you should make rooms a countainer that can hold a fixed (or dynamic) amount of entities. Then you declare friend functions which will be able to manipulate the friend functions accordingly.
-----------------------------Final Frontier Trader
What language are you programming in? A program I was doing in VB6 had a case where one object needed a reference to it's "parent". I just created a private variable, wrote a friend property for it and set that variable to nothing in the terminate event. Code sample (assumes "room" object and "thing" object):
'========================================' In Thing.cls:Private mParent as Room  Friend Property Get Parent() As Room    Set Parent = mParentEnd Property Friend Property Set Parent(vData As Room)    Set mParent = vDataEnd Property  Private Sub Class_Terminate()    Set mParent = NothingEnd Sub   '========================================' In Room.clsPrivate mThing(10) As Thing  Private Sub Class_Initialize()    Dim Counter As Long        For Counter = 1 To 10        Set mThing(Counter) = New Thing        Set mThing.Parent = Me    Next CounterEnd Sub Private Sub Class_Terminate()    Dim Counter As Long        For Counter = 1 To 10        Set mThing(Counter) = Nothing ' Automatically removes reference to parent as well    Next CounterEnd Sub 


Because this is VB you cannot 'delete' the parent, all you can do is access it and change your local reference to it. An example is so that the Thing can find out what the lighting level of the Room is, and so that the Room can notify it when something happens (you just change the "Private mParent as Room" to "Private WithEvents mParent as Room" and add event handlers). I don't have a clue how to do this in C/C++ by the way, I'm mainly a VB programmer and don't want to start messing around with QueryInterface, AddRef and ReleaseRef any time soon.

Hope that helps you.

--Thomas McCorkell

Just what is Karma? Is it a way to rate people? A way of assigning privilege levels? Or is karma just an anti-spam system?

EDIT: code tags remove any blank lines so it messed up the formatting.

[edited by - boggyb on September 1, 2002 8:45:37 AM]
This piece of randomly insane randomness was brought to you by Thomas
I dont see anything inherently wrong(or non-OOP) about having bidirectional links between two objects. However, this is a solution thats more complex and harder to maintain, so it should be avoided if its not necessary. On the other hand - if it is necessary, it would be foolish to come up with lots of hacky workarounds just to avoid that bidirectional link.

"When you know the LORD you have no need for masturbation!"
--AnkhSVN - A Visual Studio .NET Addin for the Subversion version control system.[Project site] [IRC channel] [Blog]
Ah; it is actually quite easy to maintain.

I have a situation where objects can hold other objects, and they move about quite frequently. The object MUST know what object it is in for a great many reasons, from the obvious of knowing where it is to knowing what other objects are there with it. The object class has an add function that adds an object to it. (It just maintains pointers to other objects - in this case, actually just ints that are indexes into a vector structure) This function first removes the object to be added from whatever object it is already in, then resets it''s in pointer to point to this object, then adds it to this object. In order to move an object, all I have to do is add it to the new one, and it handles all the maintanence in one spot.

This topic is closed to new replies.

Advertisement