Большой switch

[sergek]

Я понял, но ф-ция копирования не особо лепится внутри класса, т.к. он должен знать про SaveUndo, UpdateUI и др - а это к нему отношения не имеет.

Не проблема - вынесите их в отдельный класс(ы) с интерфейсными методами. Будут работать с какими-то глобальными объектами.
Свитч - всегда причина задуматься.

[Bepec]

Я с одним коллегой спорил на протяжении примерно 3 месяцев и ниразу он не смог предложить решения элегантнее и понятнее чем простой свич. Постоянно уходило в сторону шаблонов, фабрик, десятка другого классов с контролями ошибок и прочим. В результате свич на 4 действия превращался в монстра.
Поэтому я скептически отношусь к такого рода спорам.

Свич заменить можно, но только в единичных случаях это оправданно. ИМХО

[Igors]

Я понял, но ф-ция копирования не особо лепится внутри класса, т.к. он должен знать про SaveUndo, UpdateUI и др - а это к нему отношения не имеет.

Не проблема - вынесите их в отдельный класс(ы) с интерфейсными методами. Будут работать с какими-то глобальными объектами.

Не очень представляю как это. Можно (псевдо) код? Спасибо

switch простейший паттерн множественного ветвления. ...

Я искренне наслаждался почти полным отсутствием Ваших постов в течение последней пары месяцев. Увы, все хорошее так быстро кончается  

[m_ax]

Как альтернативу полиморфизму, можно использовать связку boost::variant  + соответствующий визитёр visitor

Код

C++ (Qt)
struct ID_ENABLED{};
struct ID_COUNT{};
...
 
class switch_visitor : public boost::static_visitor<>
{
public:
    void operator()(ID_ENABLED) const
    {
        // бла-бла-бла
    }
 
    void operator()(ID_COUNT) const
    {
        // бла-бла-бла
    }
 
    // и т.д.
};
 
 
boost::variant<ID_ENABLED, ID_COUNT> id = ID_COUNT();
 
 
boost::apply_visitor(switch_visitor(), id);
 

В конструктор визитора можно передавать какие-либо доп. параметры и п.р.
Пример с variant нужно воспринимать просто как альтернативу, для "подумать", возможно, подсмотреть какие-то известные решения (иначе всё "мировоззрение" так и останется замкнутым на одном лишь свитче).

[Igors]

Код

C++ (Qt)
struct ID_ENABLED{};
struct ID_COUNT{};
...
 
class switch_visitor : public boost::static_visitor<>
{
public:
    void operator()(ID_ENABLED) const
    {
        // бла-бла-бла
    }
 
    void operator()(ID_COUNT) const
    {
        // бла-бла-бла
    }
 
    // и т.д.
};
 
 
boost::variant<ID_ENABLED, ID_COUNT> id = ID_COUNT();
 
 
boost::apply_visitor(switch_visitor(), id);
 

Конечно всех деталей я не понял, но что меня смущает - классов/типов уже немало, а вот откуда возьмется нужный ф-ционал - хз. Напр UpdateUI удобно иметь методом окна, а в др методе (того же окна) сидит большой switch. Все норм. Но вот мы хотим "классами" - и надо мучительно тянуть UpdateUI  (типа корову на баню) чтобы вызвать его из того класса.

Вообще снабжать каждое поле структуры каким-то template <ID..> мне кажется не таким уж хорошим. Если это ID задается в UI - то пусть UI им и занимается, зачем это тащить в структуру данных?

[Пантер]

и надо мучительно тянуть UpdateUI  (типа корову на баню) чтобы вызвать его из того класса

Передавай сцыль на метод.

[m_ax]

Вообще снабжать каждое поле структуры каким-то template <ID..> мне кажется не таким уж хорошим. Если это ID задается в UI - то пусть UI им и занимается, зачем это тащить в структуру данных?

Я бы покурил тогда ещё вариант с мапом:

Код

C++ (Qt)
class Window
{
public:
    enum id_type { ID_ENABLED, ID_COUNT};
 
    Window()
    {
        _map[ID_ENABLED] = &Window::action_enabled;
        _map[ID_COUNT] = &Window::action_count;
    }
 
    void updateUI() { std::cout << "UbdateUI" << std::endl; }
 
    void some_method(id_type id) { _map[id](this); } // <-- Это вместо длинного свитча 
 
private:
    void action_enabled()
    {
        std::cout << "ID_ENABLED" << std::endl;
        updateUI();
    }
 
    void action_count()
    {
        std::cout << "ID_COUNT" << std::endl;
    }
 
    std::map<id_type, std::function<void(Window*)>> _map;
};
 
 
int main()
{
    Window wnd;
 
    wnd.some_method(Window::ID_COUNT);
    wnd.some_method(Window::ID_ENABLED);
 
    return 0;
}
 

Кстатии, здесь также никакого полиморфизма нет)

[Igors]

Код

C++ (Qt)
    _map[ID_ENABLED] = &Window::action_enabled;
    _map[ID_COUNT] = &Window::action_count;
 
    std::map<id_type, std::function<void(Window*)>> _map;
 

Ах какой Вы быстрый  (на заглушках ) Но напр SaveUndo - совсем не метод Window, да и UpdateUI имеет с пяток вариантов с разными параметрами. И наконец не вижу где же копируется поле структуры

[m_ax]

Но напр SaveUndo - совсем не метод Window, да и UpdateUI имеет с пяток вариантов с разными параметрами.

И в чём проблема?

И наконец не вижу где же копируется поле структуры

Думал это не требует разъяснения в этом иллюстрирующем примере..

Но.. если это так не очевидно:

Код

C++ (Qt)
typedef int MyClass;
 
class Window
{
public:
    enum id_type { ID_ENABLED, ID_COUNT};
 
    Window()
    {
        _map[ID_ENABLED] = &Window::action_enabled;
        _map[ID_COUNT] = &Window::action_count;
    }
 
    void updateUI() { std::cout << "UbdateUI" << std::endl; }
 
    void some_method(MyClass & dst, const MyClass & src, id_type id) { _map[id](this, dst, src); } // <-- Вариант свитча с копированием структуры 
 
private:
    void action_enabled(MyClass & dst, const MyClass & src)
    {
        std::cout << "ID_ENABLED" << std::endl;
        dst = src;
        updateUI();
    }
 
    void action_count(MyClass & dst, const MyClass & src)
    {
        std::cout << "ID_COUNT" << std::endl;
        dst = src;
    }
 
    std::map<id_type, std::function<void(Window*, MyClass&, const MyClass&)>> _map;
};
 
 
Window wnd;
 
    MyClass src = 1;
    MyClass dst = 2;
 
    wnd.some_method(dst, src, Window::ID_COUNT);
    wnd.some_method(dst, src, Window::ID_ENABLED);
 

  

[Igors]

Но.. если это так не очевидно:

Код

C++ (Qt)
Вариант свитча с копированием структуры 
 
private:
    void action_enabled(MyClass & dst, const MyClass & src)
    {
        std::cout << "ID_ENABLED" << std::endl;
        dst = src;
        updateUI();
    }
 

Так присваивать-то надо не всю структуру, а лишь поле (разное для разных id). Пожалуйста прочитайте мой пост #3 в начале темы где я отвечал Пантеру

[m_ax]

Так присваивать-то надо не всю структуру, а лишь поле (разное для разных id).

Я понимаю, что не всю, а лишь определённые поля для разных id.. Это же всего лишь пример..

Что в конце-концов мешает присваивать определённые поля?   В чём проблема то?

[Igors]

Что в конце-концов мешает присваивать определённые поля?   В чём проблема то?

Ну хотелось бы обобщить/схлопнуть код. А просто для каждого поля свой метод - ну я так всегда могу сделать, но это ничего не упрощает. 

[m_ax]

А просто для каждого поля свой метод - ну я так всегда могу сделать, но это ничего не упрощает.

Это разбивает весь этот длинный свитч, и локализует код для каждого действия, что уже плюс..

Ну хотелось бы обобщить/схлопнуть код.

Ну, ну

Код "не везде одинаковый". Да, в половине случаев из 100 - все одинаково как выше. В других напр UpdateUI не нужно. В других (еще более редких) нужно еще доп действие(я).

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

[Igors]

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

Не исключено что и так

Это разбивает весь этот длинный свитч, и локализует код для каждого действия, что уже плюс..

Это по меньшей мере спорно. Напр в свитче нередко удобно так

Код

C++ (Qt)
bool update = false;
switch (id) {
 case ID_ENABLE:
  ...
  update = true;
  break;
  ....
  ....
  update = true;
} 
 
if (update) {
 ...
}

А вот без свитча может оказаться совсем непросто вынести действия по update в метод

[m_ax]

Ну и что:

Код

C++ (Qt)
bool update = false;
_map[id](this, update);
 
if (update) { ... }
 

А вообще, если возникают сложности с локализацией свитча, то самое время пересматривать архитектуру, на которую, вероятно (очень вероятно),  как всегда забили)