Is unit movement on the map a matter of architecture choice?

Question

Programming

The point is this.
There is a Unit class.
There is a World class that contains an array of units and a map of the area.
It is necessary to somehow implement the movement of the unit on the map.
There are two solution methods:
1) You can create a static member - a pointer to World for the Unit class, and move the unit by calling Unit[u].Move(World.Map, new Point(x,y)). Thus, the implementation of Move() falls on the shoulders of Unit'a. The problem is that in my opinion it is bad to give a unit the ability to control the whole world.
2) You can implement Move() in the World class, and call World.Move(Unit[u], new Point(x,y). The problem is that there can be many methods (move, attack, follow, etc), and it's a bit illogical to implement unit methods in the World class
3)… maybe there are more obvious ways
how to proceed?

Answer 1

There are several options, depending on the internal implementation:
- a callback is passed to the unit, which it must pull at the end of the movement. The callback will be from the world, the position will be validated in it. According to the callback, the unit will not do anything to the world
- dispatch the event of the end of the turn to which the world is subscribed
- move the unit every update from the world (or just pull it - is it ready for checking) and validate after moving. Then validation will be at every step.