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

O>Это как раз важно !
O>Декларативные подходы в таких вещах делают архитектуру намного понятнее и намного легче расширяемой.
O>Вот пример из мануалов Boost State Machine (transition table), демонстрирующий конечный
O>автомат для CD-плеера:

O>

O>struct transition_table : mpl::vector<
O>//    Start     Event        Target      Action                      Guard 
O>//   +---------+------------+-----------+---------------------------+----------------------------+ 
O>Row  < Stopped , play       ,  Playing  , start_playback            , none                       >,
O>Row  < Stopped , open_close ,  Open     , open_drawer               , none                       >,
O>Row  < Stopped , stop       ,  Stopped  , none                      , none                       >,
O>//   +---------+------------+-----------+---------------------------+----------------------------+ 
O>Row  < Open    , open_close ,  Empty    , close_drawer              , none                       >,
O>//   +---------+------------+-----------+---------------------------+----------------------------+ 
O>Row  < Empty   , open_close ,  Open     , open_drawer               , none                       >,
O>Row  < Empty   , cd_detected,  Stopped  , store_cd_info             , good_disk_format           >,
O>g_row< Empty   , cd_detected,  Playing  , &player_::store_cd_info   , &player_::auto_start       >,
O>//   +---------+------------+-----------+---------------------------+----------------------------+ 
O>Row  < Playing , stop       ,  Stopped  , stop_playback             , none                       >,
O>Row  < Playing , pause      ,  Paused   , pause_playback            , none                       >,
O>Row  < Playing , open_close ,  Open     , stop_and_open             , none                       >,
O>//   +---------+------------+-----------+---------------------------+----------------------------+ 
O>Row  < Paused  , end_pause  ,  Playing  , resume_playback           , none                       >,
O>Row  < Paused  , stop       ,  Stopped  , stop_playback             , none                       >,
O>Row  < Paused  , open_close ,  Open     , stop_and_open             , none                       >
O>//   +---------+------------+-----------+---------------------------+----------------------------+ 
>> {};
O>

4 состояния и 9 переходов — это не истересно. Вы перепишите для предложеной задачи и хотя бы для 2-х шагов, тогда и поймете в чем отличие.

O>Ну напишите то же самое на if-ах — думаете, получится проще ?

То же самое — не будет проще. А вот задача топикстартера точне не станет проще, если ее переписать на конечных автоматах.

O>А ведь данный фреймворк предоставляет множество вспомогательных методов, if-ами это не переплюнуть.

Бла-бла-бла.

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

L>>4 состояния и 9 переходов — это не истересно.

O>Кто бы сомневался.

Зачем тогда приводить пример, который неинтересен в рамках предмета обсуждения?

L>>Вы перепишите для предложеной задачи и хотя бы для 2-х шагов, тогда и поймете в чем отличие.

O>С какой целью мне это делать ?

С целью показать, что этот подход применим к рассматриваемой задаче.

O>Наглядность подхода, использующего state machine, я уже продемонстрировал, пусть на простом
O>примере, но все же не настолько упрощенном.

А своим нежеланием рассматривать исходную задачу продемонстрировали неприменимость конечных автоматов в этом случае.

O>То, что состояний будет на порядок больше мне известно, а вот как то же самое
O>запрограммировать if-ами посмотрел бы.

А чего там демонстрировать-то?
currentStep.CustomerName.Visible = prevStep.CustomerSelected;

И так для каждого контрола.

O>>>А ведь данный фреймворк предоставляет множество вспомогательных методов, if-ами это не переплюнуть.

L>>Бла-бла-бла.

O>Расцениваю это как неуважение и дальнейшая дискуссия мне неинтересна.

Расцениваю это как слив и можете дальше продолжать не интересоваться этой дискуссией.

Есть задачка.
Необходимо написать конфигуратор. Если на первом шаге выбрано это, то на втором доступны только эти, либо эти опции.
Что то типа "Гуру" на market.yandex.ru . Количество шагов для выбора у меня планируется >10 с кучей условий на каждом шаге.
Естественно до меня уже эта тема хорошо проработана. Только вот каково название таких систем?
Вопрос как они называются на английском? И есть ли какие нибудь свободные движки или библиотеки для таких проектов?

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

_>Есть задачка.
_>Необходимо написать конфигуратор. Если на первом шаге выбрано это, то на втором доступны только эти, либо эти опции.
_>Что то типа "Гуру" на market.yandex.ru . Количество шагов для выбора у меня планируется >10 с кучей условий на каждом шаге.
_>Естественно до меня уже эта тема хорошо проработана. Только вот каково название таких систем?
_>Вопрос как они называются на английском? И есть ли какие нибудь свободные движки или библиотеки для таких проектов?

Конечные автоматы.
State-machine или как-то так.
Движки есть, язык программирования какой ?

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

_>>Вопрос как они называются на английском? И есть ли какие нибудь свободные движки или библиотеки для таких проектов?

O>Конечные автоматы.
O>State-machine или как-то так.

И что тут будет являться состоянием?

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

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

_>>>Вопрос как они называются на английском? И есть ли какие нибудь свободные движки или библиотеки для таких проектов?

O>>Конечные автоматы.
O>>State-machine или как-то так.

L>И что тут будет являться состоянием?

Конфигурация.

decision tree?

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

O>>>State-machine или как-то так.

L>>И что тут будет являться состоянием?

O>Конфигурация.

Конфигурация — это совокупность всех опций или что-то дугое?

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

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

O>>>>State-machine или как-то так.

L>>>И что тут будет являться состоянием?

O>>Конфигурация.

L>Конфигурация — это совокупность всех опций или что-то дугое?

Комбинация опций на определенном шаге выбора.

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

_>Есть задачка.
_>Необходимо написать конфигуратор. Если на первом шаге выбрано это, то на втором доступны только эти, либо эти опции.
_>Что то типа "Гуру" на market.yandex.ru . Количество шагов для выбора у меня планируется >10 с кучей условий на каждом шаге.
_>Естественно до меня уже эта тема хорошо проработана. Только вот каково название таких систем?
_>Вопрос как они называются на английском? И есть ли какие нибудь свободные движки или библиотеки для таких проектов?
Экспертные системы. Причем предлагают варианты сначала более вероятные. Требуют обучения

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

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

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

O>>>>>State-machine или как-то так.

L>>>>И что тут будет являться состоянием?

O>>>Конфигурация.

L>>Конфигурация — это совокупность всех опций или что-то дугое?

O>Комбинация опций на определенном шаге выбора.
Типа этого?
http://www.codeproject.com/KB/WPF/wizarddialog.aspx

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

O>>>Конфигурация.

L>>Конфигурация — это совокупность всех опций или что-то дугое?

O>Комбинация опций на определенном шаге выбора.

Вы себе представляете в какое кол-во состояний это выльется?

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

L>Вы себе представляете в какое кол-во состояний это выльется?

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

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

L>>Вы себе представляете в какое кол-во состояний это выльется?

O>Конечно представляю.
O>Но задача не может быть проще, чем она есть на самом деле.

Зато она может быть сделана сложнее на пустом месте. С использованием конечного автомата.

O>Если шагов больше десяти, и на каждом несколько своих веток, то
O>тут вообще не важно какой подход применять, потому что вариантов
O>все равно будет как в шахматах — триллионы.

void Test(bool a, bool b, bool c, bool d, bool e)
{
  if (a)
    Console.WriteLine("a");
  if (b)
    Console.WriteLine("b");
  if (c)
    Console.WriteLine("c");
  if (d)
    Console.WriteLine("d");
  if (e)
    Console.WriteLine("e");
}

Если пишем так, то получаем 5 if-ов. Если зпишем в стиле конечного автомата, то получим 32 if-а.
Вы все еще уверены, что не важно, какой подход применять?

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

L>Вы все еще уверены, что не важно, какой подход применять ?

Из вводных данных (весьма скудных): "если на первом шаге выбрано это, то на втором доступны только эти,
либо эти опции" и "количество шагов для выбора у меня планируется >10 с кучей условий на каждом шаге".

L>

L>void Test(bool a, bool b, bool c, bool d, bool e)
L>{
L>  if (a)
L>    Console.WriteLine("a");
L>  if (b)
L>    Console.WriteLine("b");
L>  if (c)
L>    Console.WriteLine("c");
L>  if (d)
L>    Console.WriteLine("d");
L>  if (e)
L>    Console.WriteLine("e");
L>}
L>

Искусно подобранный пример. И сильно упрощенный.

Здравствуйте, Lloyd.

Только сейчас обратил внимание:

L>Если запишем в стиле конечного автомата, то получим 32 if-а.

Если реализовывать конечный автомат на if-ах, то в этом никакого смысла, разумеется, нет.
Но есть специальные программные фреймворки для построения конечных автоматов,
где комбинации описываются декларативно.

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

L>>Вы все еще уверены, что не важно, какой подход применять ?

O>Из вводных данных (весьма скудных): "если на первом шаге выбрано это, то на втором доступны только эти,
O>либо эти опции" и "количество шагов для выбора у меня планируется >10 с кучей условий на каждом шаге".

Вы не закончили предложение.

L>>

L>>void Test(bool a, bool b, bool c, bool d, bool e)
L>>{
L>>  if (a)
L>>    Console.WriteLine("a");
L>>  if (b)
L>>    Console.WriteLine("b");
L>>  if (c)
L>>    Console.WriteLine("c");
L>>  if (d)
L>>    Console.WriteLine("d");
L>>  if (e)
L>>    Console.WriteLine("e");
L>>}
L>>

O>Искусно подобранный пример. И сильно упрощенный.

Ничего искусного, и да, сильно упрощенный. В действительности все будет сложнее.

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

L>>Если запишем в стиле конечного автомата, то получим 32 if-а.

O>Если реализовывать конечный автомат на if-ах, то в этом никакого смысла, разумеется, нет.
O>Но есть специальные программные фреймворки для построения конечных автоматов,
O>где комбинации описываются декларативно.

Это не важно, как это записывать. Кол-во таких if-ов == кол-ву состояний конечного автомата. И каждое состояние придется выписывать + выписывать правила перехода. Для пяти входных параметров уже 32 выходных, для заявленных автором 10 будет уже 1024 состояния.

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

L>Это не важно, как это записывать. Кол-во таких if-ов == кол-ву состояний конечного автомата. И каждое состояние придется выписывать + выписывать правила перехода. Для пяти входных параметров уже 32 выходных, для заявленных автором 10 будет уже 1024 состояния.

Это как раз важно !
Декларативные подходы в таких вещах делают архитектуру намного понятнее и намного легче расширяемой.
Вот пример из мануалов Boost State Machine (transition table), демонстрирующий конечный
автомат для CD-плеера:

struct transition_table : mpl::vector<
//    Start     Event        Target      Action                      Guard 
//   +---------+------------+-----------+---------------------------+----------------------------+ 
Row  < Stopped , play       ,  Playing  , start_playback            , none                       >,
Row  < Stopped , open_close ,  Open     , open_drawer               , none                       >,
Row  < Stopped , stop       ,  Stopped  , none                      , none                       >,
//   +---------+------------+-----------+---------------------------+----------------------------+ 
Row  < Open    , open_close ,  Empty    , close_drawer              , none                       >,
//   +---------+------------+-----------+---------------------------+----------------------------+ 
Row  < Empty   , open_close ,  Open     , open_drawer               , none                       >,
Row  < Empty   , cd_detected,  Stopped  , store_cd_info             , good_disk_format           >,
g_row< Empty   , cd_detected,  Playing  , &player_::store_cd_info   , &player_::auto_start       >,
//   +---------+------------+-----------+---------------------------+----------------------------+ 
Row  < Playing , stop       ,  Stopped  , stop_playback             , none                       >,
Row  < Playing , pause      ,  Paused   , pause_playback            , none                       >,
Row  < Playing , open_close ,  Open     , stop_and_open             , none                       >,
//   +---------+------------+-----------+---------------------------+----------------------------+ 
Row  < Paused  , end_pause  ,  Playing  , resume_playback           , none                       >,
Row  < Paused  , stop       ,  Stopped  , stop_playback             , none                       >,
Row  < Paused  , open_close ,  Open     , stop_and_open             , none                       >
//   +---------+------------+-----------+---------------------------+----------------------------+ 
> {};

Ну напишите то же самое на if-ах — думаете, получится проще ?
А ведь данный фреймворк предоставляет множество вспомогательных методов, if-ами это не переплюнуть.

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

L>4 состояния и 9 переходов — это не истересно.

Кто бы сомневался.

L>Вы перепишите для предложеной задачи и хотя бы для 2-х шагов, тогда и поймете в чем отличие.

С какой целью мне это делать ?
Наглядность подхода, использующего state machine, я уже продемонстрировал, пусть на простом
примере, но все же не настолько упрощенном.
То, что состояний будет на порядок больше мне известно, а вот как то же самое
запрограммировать if-ами посмотрел бы.

O>>А ведь данный фреймворк предоставляет множество вспомогательных методов, if-ами это не переплюнуть.

L>Бла-бла-бла.

Расцениваю это как неуважение и дальнейшая дискуссия мне неинтересна.

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

O>Ну напишите то же самое на if-ах — думаете, получится проще ?

Получится 1-в-1:

//    Start               Event                        Guard   Target          Action 
//   +-------------------+----------------------------+-------+---------------+----------------+ 
if(   state == Stopped && event.type == play       && true ) { state = Playing; start_playback }
if(   state == Stopped && event.type == open_close && true ) { state = Open;    open_drawer    }

И никакие вспомогательные методы не помогут поддерживать эту декларативную тыщщу строк