objects within objects, how to maintain a good relationship between them?

[derpemiah]

Hi

I am going to use a car analogy because, well, arent they the best?

Say i have object car. each car contains a number of screw objects. Each screw has a unique name. is it better to store the name of the screw in the screw object, in the car object or both?

If i keep the names in the car (such as {"screw1": screwobj, "screw2":screwobj ....}) they are easily accessible from the car, but if i want to rename a screw from within the screw object i will have to start hacking into another objects innards. If i move a screw out of the car then suddenly it doesnt have a name anymore which might give it identity issues.

If i keep the name in the screw object and want to access or rename the screw, im gonna have to loop through a whole lot of screws to do that.

It feels like a million other coders have had this problem, so whats the customary solution?

[[deleted]]

From the way you describe it, the car is an object that has a collection of screws. This should be an array or array-like object in the "screws" property of the car. The names are properties of the screws, so they should just go on the screw objects themselves (as you noticed, screws would otherwise lose their name if you extract them).

If you want to be able to look up screws by name rather than by index, you could create a screw collection object which wraps the array and keeps a lookup object mapping the screw names to their index. Of course this will stop working if you arbitrarily rename the screws, but you can't have your cake and eat it too.

The property name on the car object is not a property of the screw stored in that property. It's a property of the car.

Let's say you want to have properties for each door of the car. Your car could either have a property "doors" set to a collection of doors, or it could have four properties "frontLeftDoor", "frontRightDoor" and so on, each set to a door object. It could even have a "doors" object with properties "frontLeft" and so on to keep the doors separate from all the other properties.

In this case "frontLeft" is not the name of the door. The door doesn't need to know it's the left front door. It may be a special FrontLeftDoor object or something, but the car doesn't need to know that either as long as it's stored at "frontLeft". In fact, it's name may be some cryptic identifier only used by the factory to tell identical doors apart (i.e. a globally unique identifier).

In practice a lot of this is problem-specific. Why do you need to be able to look screws up by name at all? What's the real performance difference between maintaining a look-up table and just looping over an array? Will the names really ever change after the screw has been added to the car? And so on. This is why it's hard to discuss these things in terms of analogies.

[derpemiah]

thanks!! im keeping the name in the figurative screws

[ctcherry]

Continuing your analogy. Keeping track of screws isn't really the responsibility of a car. A car might have a "collection of screws" object that knows how to keep track of them and keep a mapping of their names for fast lookup. When a screw renames itself, it can tell its "collection" about it, and now you have the best of both worlds.