Class Responsibility, Does my 'Mobile Object' class actually care that it is moving?

Question

I'd like some guidance on which class should hold certain information. If I have a 'Mobile Object' that moves around within a 'Space Object,' does the Mobile Object really care where it is within the Space Object, how fast it's moving, and in which direction?

It certainly seems convenient to assign a property to the Mobile Object for 'Location,' but I don't think it really has any concern for that. So I've come up with:

class Mobile
    {        
        //some properties/fields/etc

        event EventHandler<MovementEventArgs> move;

        public void Move(Vector direction)
        {
            raiseMove(direction);
        }

        private raiseMove(Vector direction)
        {
            EventHandler<MovementEventArgs> handler = move;
            if (move != null)
                handler(this, New MovementEventArgs(direction));
        }
    }

class Space
    {
        Mobile someObject;
        Vector someObjectLocation;

        public Space()
        {
            someObject = new someObject();
            someObject.Move += HandleMobileMove;
        }

        public void MoveSomeObject(Vector direction)
        {
            someObject.Move(new Vector(1,0));
        }

        private void HandleMobileMove(object sender, MovementEventArgs e)
        {
            someObjectLocation += e.Direction;
        }
    }

That's a bit hastily written... but I hope it gets my point across. In summary: should the Mobile hold a location, or the Space? Who should control the movement?

Answer 1

In WPF, the Canvas object is responsible for knowing the location of its children. That would lend credence to your approach (which uses a similar structure as an Attached Property).

If you are uncomfortable with the location being stored in the Space object, you could also use the Decorator pattern to attach additional information to the Mobile objects. This would give you the option of positioning an object or not, without the object itself caring.

When getting the collection of children, you could filter out only those objects which employ your location decorator (perhaps using the OfType extension method) and do what you need with them. You'll have to convert to using interfaces rather than hard class references. That would probably be a good thing, though.

In the end, though, it depends on what your Space and Mobile objects are doing. If the Space object is displaying the Mobile objects (like Canvas), then it needs to know location information but the Mobiles don't. On the other hand, if the Mobiles themselves are using their location information to track something or perform some task (and the Space object doesn't care, perhaps only providing bounds, etc.), then it may be best to store that information with them.

To drive the point home a bit further, ask yourself this question: if I change the location, who cares? A Control is WPF is generally not affected by its Top and Left coordinates but its container control is, so it makes sense to store that information in the container. If you change the location of a Mobile, does that have any effect on the Mobile or how it does its job? Does Space behave differently if Mobile X moves from Y to Z?

Answer 2

Thinking in purely OOP terms, I would argue that these should certainly be properties of the mobile object in the same way that my position and velocity are properties of me as I move through space. If your space object needs to access these properties for bounds checking, it can retrieve them from public get methods on the mobile instances.

Answer 3

Your argument is logical, but think about the wastefulness of someObject.Move += HandleMobileMove; and your implementation (someObjectLocation +=): essentially you're wasting the this pointer. Your Mobile certainly has a 1:1 relationship with its Location and I would expect a Space class to have a 1:M relationship to Mobile (unless you have only 1 object in space). In your design, that requires your Space to maintain the association of Mobile to Location, which is cumbersome, especially since the alternative is simply to make Location an element of your Mobile.