Здравствуйте!

Пожалуйста подскажите мне. Есть определенный flow(какие диалоги показывать, что печатать, в какой момент сохранять данные, в общем список действий) у приложения. Данное приложение взаимодействует с внешним приложением и получает от него данные. Примерно выглядит так (наше приложение — B):

1. A sends data to B. [switch application]
2. B choose flow1 or flow2.
3. B sends data to A. [switch application]
4. A accept(продолжение) or decline(отмена).
5. A sends data to B. [switch application]
6. B continues started flow.
7. B sends data to A. [switch application]

Проблема вся в том, что приложения после передачи данных "выключаются" (заканчивают свою работу, и к сожалению изменить это невозможно, второе приложение по настоящему сторонее ).
Каждое приложение может сохранять свои данные в файле.
flow1 и flow2 разбивается на шаги, например, спросить у пользователя какая погода, спросить у пользователя какое у него настроение, и т.п.

У меня родилась идея, разбив каждый flow на шаг, реализовать имплементации в субклассах некоего абстрактного Step.
При первом старте приложения (в данных переданных от A ясно что это второе включение приложения B) мы выбираем flow и сохраняем шаги в списке. Далее приложение перед тем как отдать управление просто сохраняет список шагов в файле и при последующем старте восстанавливает и продолжает свою работу по сохраненным шагам. Может у вас есть критика к данному подходу или может что будет действительно лучше идея как это реализовать. В действительности сейчас реализовано на switch-ах, выглядит убого:

switch (state)
{
//...
case 6:
  //...
  state += 1;
  break;
//...
}

Язык имплементации C++.

Заранее благодарю за помощь, и надеюсь на ваше понимание.

Здравствуйте, zubr, Вы писали:

А почему нельзя не завершать работу B ? Всё таки это Ваше приложение. Ещё мне интересно: если при первом запуске B выполнялась печать, то при втором запуске, для того чтоб восстановить исходное состояние, опять придётся печатать? Или некоторые типы шагов (подклассы Step'а) будут считаться "незначимыми" ? Лично у меня, когда при анализе предметной области начинают сильно часто всплывать слова "шаг","переход", "состояние", "процесс обработки", появляется сильнейший зуд сделать конечный автомат. Вот и в данном случае мне такой подход кажется логичным. По сути от Вашего варианта только отличется тем, что больше работы будет делаться при 1-м запуске и сохраняться будет уже состояние, а не шаги, приведшие к этому состоянию.

ЗЫ.
Да, можно не так круто использовать архитекторскую терминологию? А то я долго вникал в смыл фразы "реализовать имплементации в субклассах некоего абстрактного Step"

Здравствуйте, Mazay, Вы писали:

M>Здравствуйте, zubr, Вы писали:

M>А почему нельзя не завершать работу B? Всё таки это Ваше приложение.
"Такая вот загогулина..." (C) К сожалению нет многозадачности, и к еще большему сожалению это уже не исправить.
M>Ещё мне интересно: если при первом запуске B выполнялась печать, то при втором запуске, для того чтоб восстановить исходное состояние, опять придётся печатать?
Неа, печатать ненадо! как раз надо пропустить все, что было сделано и приступить к следующему шагу.
Мне кажется можно сохранить текущее состояние на диск, а потом просто перепрыгнуть на нужный шаг
А ваша идея с конечным автоматом понравилась. Причем сохранение в данном случае будет всего лишь сохранение состояния в котором мы остановили работу приложения. К сожалению не получится сделать переход из стартового состояния во втором включении, необходимо обязательно знать из какого места продолжать работу.

M>ЗЫ.
M>Да, можно не так круто использовать архитекторскую терминологию? А то я долго вникал в смыл фразы "реализовать имплементации в субклассах некоего абстрактного Step"
уху извините