[Pitty]

Насчёт робота.
Мне кажется, оба метода: функциональный и объектный, имеют право на существование в этом случае. Удобство функционально - не надо создавать лишней инфраструктуры, удобство ООП - маштабируемость, но тогда приходится заранее продумывать все будущие ходы, чего сделать, в принципе, не возможно.
Например, движение. Базовая функция: AsyncResult BeginMoveTo(float X, Float Y, Float Z, Float Velocity)
Которая в свою очередь вызывает несколько функций: определение текущих координат, определение возможности проезда к нужным координатам/построение пути. Как только задан путь, вызывается функция AddMovingTask, которой передается путь, и она возвращает в свою очередь объект AsuncResult (ну еще колбэк нужен). В то же время существует бесконечный цикл, назовем его диспетчер задач, который, получив задание начинает его в цикле выбирать. При этом, вполне чётко можно проследить модульность: если изменится базовый алгоритм движения, необходимо будет изменить только тело функции DoStep, которая вызывается диспетчером. Если мы найдем более совершенный алгоритм нахождения пути - поменять только алгоритм метода поиска пути....
Мне кажется, как раз в этом случае создание объектной модели было бы излишним. Если вы строите робота-игрушку, у вас и аппаратные средства будут соответствующие, если вы строите боевого робота - там уже тем более будет не хватать аппаратных средств, т.к. скорость реакции и точность расчёта повышаются в несколько раз (да и количество задач тоже). По моим данным, в роботостроении мало применяется ООП. (Правда они немного устарели, года на 3-4).
Кстати, это пример чисто теоретический или Вы имеете практические намерения? В)
Не знаю, почему вы так обозлились на конечные автоматы: ведь практически реализуемый автомат всегда можно реализовать/оптимизировать, причём есть автоматические алгоритмы для таких вещей (универсальные).