Проблема Шаблона разработки, включающая N состояния и переходы между ними

[разве] эти не укажет, что образец делает работу?

Если аргумент только входное STD :: string Как это

std::string text("Hello");
w32function(text.c_str());

Если аргумент вход / вывод Использование STD :: Vector Вместо этого:

std::string input("input");
std::vector<char> input_vec(input.begin(), input.end());
input_vec.push_back('\0');
w32function(&input_vec[0], input_vec.size());
// Now, if you want std::string again, just make one from that vector:
std::string output(&input_vec[0]);

Если аргумент - только выход также использовать STD :: Vector , как это:

// allocates _at least_ 1k and sets those to 0
std::vector<unsigned char> buffer(1024, 0);
w32function(&buffer[0], buffer.size());
// use 'buffer' vector now as you see fit

Вы также можете использовать std :: basic_string и std :: vector , если это необходимо.

Вы можете прочитать больше на тему в книге Эффективным STL Скотт Мейерс.

Первое, что я заметил в вашем примере, это состояние 3 = (состояние 1 == True && State 2 == TRUE). Это не будет масштабироваться очень хорошо, как вовлечены более возможные состояния. Если вы рассматриваете только, стоит ли идти дождь или в воскресенье, вы можете иметь в воскресенье, у вас может быть перечисление, с 4 возможными типами:

enum State { CLEAR_OTHER_DAY, RAINING_OTHER_DAY, CLEAR_SUNDAY, RAINING_SUNDAY }

Это позволит вам очистить условия чисто в блоке переключателя, когда настало время для кода. Но если вы также должны рассмотреть, тепло его на улице, вы должны добавить еще 4 значения для захвата всех возможных условий. А позже в вашем проекте ваш код может потребоваться запечатлеть больше условий, чем вы в настоящее время представите.

Что касается структуры дизайна, узор состояния и его пример Java на Wikipedia выглядят как хорошее место для начала.

Пример Википедии имеет StateContext класс со способом, называемым SetState , который принимает имя. Я подумал, что вы предложили, что вы добавляете логику определения состояния здесь, но это сделало бы вашу StateContext классом классом. Было бы лучше поставить метод определения состояния системы в классе, который бы легко узнал условия для перехода от одного государства в другое. Таким образом, если ваш проект должен измениться в будущем, и у вас есть больше государств для отслеживания или разных условий, вам нужно только поддерживать логику в одном месте.

Это походит на типичное использование для конечный автомат

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

в коде, вы могли сделать конечный автомат как это:

 enum State { Init, ShowMenu, ShowMsg, DisplayVideo, Exit };
 State state = State.Init;

 while (state != State.Exit)
 {
      switch(state)
      {
           case State.Init:
                init();
                state = State.ShowMenu;
                break;
           case State.ShowMenu:
                if(lastMenuItemSelected==1) state = State.ShowMsg;
                if(lastMenuItemSelected==2) state = State.DisplayVideo;
                break;
           case State.ShowMsg:
                ....
                break;
           ....
 }

я не уверен, получил ли я точный синтаксис, корректный для Java... Я больше в C#

Как и другие, говорили, что государственный аппарат может быть смоделирован в процедурном коде с выключателем или в коде OO с шаблоном состояния, который, вероятно, что вы были после.

Однако 3-й способ - фактически кодировать его как график, с состояниями как узлы и условия в качестве направленных ребер. Затем рисунок посетителей может использоваться для применения графика к другому применению. Это обеспечит особенно хорошо конструирует, где могут быть определены состояния и / или переходы, но, вероятно, будут более интенсивно памятью, затем жесткими кодированными станками, описанными в других ответах.