State pattern
нет. в "классическом" будет базовый State класс, от которого производятся классы по одному на конкретное состояние. машина выбирает сообщение/событие из очереди и отправляет его текущему состоянию, тот знает, как поступить с каждым типом сообщения.
в "альтернативном" будет базовый Event(Handler) класс (а не State в обоих случаях, как у вас), от которого производятся классы по одному на конкретный тип события. машина выбирает сообщение из очереди, как и в классиме, но отправляет его обработчику данного события, передавая ему значение текущего состояния.
в принципе обработкой занимается тот же метод, но находим его в одном случае сперва по икс-координате, затем - по игрек, в другом случае - наоборот. попадаем в ту же точку.
сделал прототипы обоих вариантов, классика выглядит немного проще. разница незначительна, и
все что составляет "разницу" находится в автоматически генерируемой части кода, но все-таки остановлюсь на классическом. хотя альтернативный тоже вполне работоспособный. принципиальных препятствий не встретил.