Archived

This topic is now archived and is closed to further replies.

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

This topic is 5587 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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?

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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 = mParent
End Property

Friend Property Set Parent(vData As Room)
Set mParent = vData
End Property


Private Sub Class_Terminate()
Set mParent = Nothing
End Sub



'========================================
' In Room.cls
Private 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 Counter
End 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 Counter
End 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]

Share this post


Link to post
Share on other sites
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!"

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites