Название: Нетипичное наследование Отправлено: ecspertiza от Октябрь 10, 2017, 18:52 Реализую у себя в коде возможность выполнения неких команд. Команда перед запуском должна быть проверена, может ли она быть запущена.
Есть вот такой пример Код: #include <iostream> Функция checkCommand просто для примера, она будет сильно расширена, и хочется что бы она работала с базовым классом. В текущем коде не нравится то, что команды создаются до того как произошла проверка на запуск. Вопрос как в данном случае можно выполнить эту проверку до того как создан экземпляр команды? Думал сделать dublicated статичной, но статичные виртуальные функции не поддерживаются. Название: Re: Нетипичное наследование Отправлено: ssoft от Октябрь 11, 2017, 07:59 Можно не создавать команду, можно проверить по типу сначала
Код: bool checkCommand(BaseCommand::CommandType type) Название: Re: Нетипичное наследование Отправлено: ecspertiza от Октябрь 11, 2017, 09:56 Необходимо проверить флаг dublicated, если он false то запретить создавать дубликат команды. В примере выше не понятно откуда берется переменная command.
Название: Re: Нетипичное наследование Отправлено: ssoft от Октябрь 11, 2017, 10:27 Наверное так ???
Код: int main(int argc, char *argv[]) Название: Re: Нетипичное наследование Отправлено: ecspertiza от Октябрь 11, 2017, 10:29 Теперь нет возможности получить из потомка флаг dublicable ;-) То есть он по дефолту проверяется. А проверка должна происходить в зависимости от флага deblicable потомка.
Название: Re: Нетипичное наследование Отправлено: ssoft от Октябрь 11, 2017, 10:38 Если dublicable является неизменяемым свойством для каждого типа команд, то можно метод оформить, как статический.
Код: class BaseCommand Если же это свойство конкретного экземпляра команды (экземпляры одного класса могут быть как dublicated, так и нет), тогда уже придется создавать экземпляр. Название: Re: Нетипичное наследование Отправлено: ecspertiza от Октябрь 11, 2017, 10:58 Изменяемо для каждого типа.
Название: Re: Нетипичное наследование Отправлено: m_ax от Октябрь 11, 2017, 13:47 Изменить архитектуру, заменив функцию checkCommand на
Код
Название: Re: Нетипичное наследование Отправлено: ecspertiza от Октябрь 11, 2017, 13:53 m_ax, если не ошибаюсь тут тоже есть создание команды, потом проверка. И в случае если проверка не прошла, command будет автоматически удален. Буду мудрить с типами и switch.
Название: Re: Нетипичное наследование Отправлено: m_ax от Октябрь 11, 2017, 13:58 m_ax, если не ошибаюсь тут тоже есть создание команды, потом проверка. И в случае если проверка не прошла, command будет автоматически удален. Буду мудрить с типами и switch. Конечно есть создание команды, ведь далее вызывается её метод (а как его вызвать без создания объекта?) :)Название: Re: Нетипичное наследование Отправлено: ecspertiza от Октябрь 11, 2017, 14:03 Статик :-)
Вообще не хватает мета информации о типе, которую можно было бы проверять. Задал свойства команды в мета информацию. Проверил ее, она не изменяема и статична для каждого типа. При этом эту мета информацию можно было бы для потомков переопределять. Название: Re: Нетипичное наследование Отправлено: m_ax от Октябрь 11, 2017, 15:56 Вообще не хватает мета информации о типе, которую можно было бы проверять. Задал свойства команды в мета информацию. Проверил ее, она не изменяема и статична для каждого типа. При этом эту мета информацию можно было бы для потомков переопределять. Ну это типичный паттерн type_traits и плюс немного меташаблонной магии от boost::variant и boost::static_visitorКод Писалось на коленке, могут быть опечатки :) Название: Re: Нетипичное наследование Отправлено: ecspertiza от Октябрь 11, 2017, 16:49 Спасибо, гляну этот паттерн.
Название: Re: Нетипичное наследование Отправлено: ViTech от Октябрь 11, 2017, 17:07 Статик :-) Вообще не хватает мета информации о типе, которую можно было бы проверять. Задал свойства команды в мета информацию. Проверил ее, она не изменяема и статична для каждого типа. При этом эту мета информацию можно было бы для потомков переопределять. В класс добавьте статичных констант и переопределяйте их в потомках. Правда не очень понятно, как вы это всё использовать хотите. Название: Re: Нетипичное наследование Отправлено: Old от Октябрь 11, 2017, 17:17 Код
Название: Re: Нетипичное наследование Отправлено: ecspertiza от Октябрь 11, 2017, 19:13 Вот такие две штуки получились
Код: #include <iostream> Код: #include <iostream> Название: Re: Нетипичное наследование Отправлено: ViTech от Октябрь 11, 2017, 20:43 Оффтоп. Вместо такой вереницы:
Код можно так: Код
Название: Re: Нетипичное наследование Отправлено: sergek от Октябрь 11, 2017, 22:38 тогда уж так:
Код: for (auto command : m_arr) Название: Re: Нетипичное наследование Отправлено: Igors от Октябрь 12, 2017, 08:15 В текущем коде не нравится то, что команды создаются до того как произошла проверка на запуск. Вопрос как в данном случае можно выполнить эту проверку до того как создан экземпляр команды? Чтобы выполнить проверку нужны те или иные данные для каждого типа команды (класса). Поэтому создавать какой-то класс все равно придется, и развивать его тоже (на виртуалах или темплейтах). Такой класс мне кажется искусственным, лучше обойтись одним классом "команда", т.е. по сути оставить как было. А проверку можно сделать в конструкторе, если не проходит - взвести флажок и быстренько выйти.Код
Название: Re: Нетипичное наследование Отправлено: Old от Октябрь 12, 2017, 08:20 А проверку можно сделать в конструкторе Как в конструкторе команды сделать проверку, что там есть в очереди команда? Передавать в конструктор команды очередь команд? :)взвести флажок и быстренько выйти. Удобно, чО. :)Код
Название: Re: Нетипичное наследование Отправлено: ecspertiza от Октябрь 12, 2017, 10:04 Передавать в конструктор команды очередь команд? :) И да будет спагетти :-) Название: Re: Нетипичное наследование Отправлено: Igors от Октябрь 12, 2017, 11:24 И да будет спагетти :-) Какое спагетти? Откуда ??? Код Вот я смотрю на этот кусочек и в упор не вижу - ну что же тут такого плохого? Да, создали экземпляр, он выполнил проверку - совершенно логично и ессно, он может и должен проверять, у него для этого все есть. Ну может else delete выглядит чуть неуклюже - так это легко уладить хотя бы однострочным inline. Но вместо этого мы лепим еще какую-то хренотень которая что-то решает за класс команды. Хотя тот же is_single прямо-таки просится быть членом класса команда. И я даже знаю почему так делается :) Хочется блеснуть владением темплейтами - и все, объективных оснований никаких Название: Re: Нетипичное наследование Отправлено: Old от Октябрь 12, 2017, 11:35 Вот я смотрю на этот кусочек и в упор не вижу - ну что же тут такого плохого? Вот это и плохо. Не всегда конструктор ничего не делает.Для чего конструировать объект, который не нужен и потом его разрушать, если достаточно статических данных? Название: Re: Нетипичное наследование Отправлено: ecspertiza от Октябрь 12, 2017, 11:59 Old, согласен, об этом и был основной вопрос топика.
Igors, пример который есть выше, он просто описывает проблему. В реале же, это цела структура. Создания, проверки, регистрирования команд, на выполнение. У нас есть менеджер который проверят возможность исполнения команды, при необходимости регистрирует ее и запускает на исполнение. В вашем примере, нам придется в каждую команду передать массив действий, например для того что бы проверить команды на дублирование. Получается, что каждая отдельная операция будет знать о соседних. Зачем ей это? Это уже нарушение архитектуры. Команда должна знать только о своих свойствах и действиях которые ей необходимо выполнить. Остальное должен разруливать менеджер (в примере выше это main и checkExecutable). Шаблоны же в данном случае помогают нам решить несколько проблем 1. Конфигурирование свойств команды на этапе ее описания. Мы не ломаем ООП. Как в случае, со статичными методами для каждого дочернего класса. 2. Проверка этих свойств без создания самой команды. Название: Re: Нетипичное наследование Отправлено: ViTech от Октябрь 12, 2017, 12:56 тогда уж так: Код: for (auto command : m_arr) Хорошо, конечно, всё на компилятор скинуть, но это может привести к тому, что разработчики думать совсем перестанут. Тогда уж так: Код: for (auto & command : m_arr) Но, на мой взгляд, читабельность страдает. Всё хорошо в меру :). Название: Re: Нетипичное наследование Отправлено: Авварон от Октябрь 12, 2017, 17:05 auto&& тогда уж и не думать)
Название: Re: Нетипичное наследование Отправлено: Igors от Октябрь 12, 2017, 17:32 Шаблоны же в данном случае помогают нам решить несколько проблем.. Простой пример с is_single можно делать как угодно, напр мапой. Вопрос в дальнейшей расширяемости, гибкости и удобстве. И тут, полагаю, Вас привлекло этоКод Мол, если возникнет какая-то специфика для др команды - мы специализируем для нее шаблон, и все дела! (поправьте если не так понял). Ну то смотря как (или куда) проверки разрастутся. У checkCommand должны быть данные команды чтобы он мог что-то решать. А как их получить если экземпляра нет? На одних статиках далеко не уехать. В вашем примере, нам придется в каждую команду передать массив действий, например для того что бы проверить команды на дублирование. Получается, что каждая отдельная операция будет знать о соседних. Зачем ей это? С этим согласен. Но можно без затей создать экземпляр и подать его менеджеру - пусть он решает. Не вижу зачем (упорно) избегать создания экземпляра - это уже обошлось недешево, код заметно усложнился.Название: Re: Нетипичное наследование Отправлено: m_ax от Октябрь 12, 2017, 20:47 Цитировать auto&& тогда уж и не думать) А чем это лучше auto & ? На сколько я понимаю, (возможно я не прав) это вызовет копирующий конструктор.. Цитировать Мол, если возникнет какая-то специфика для др команды - мы специализируем для нее шаблон, и все дела! Да, именно так. Это тот самый случай, когда необходимо разруливать (развлетвлять) поведение системы в зависимости только от пренадлежности её к определённому типу, минуя необходимость создавать объект класса.. Это классический паттерн класс харрактеристик (type traits). И да, он работает (и как это видно из контекста) в тех случаях, когда "checkCommand не обязан иметь внутренние данные команды чтобы он мог что-то решать." :) Короче, всё решается в зависимости только от типа.Название: Re: Нетипичное наследование Отправлено: Old от Октябрь 12, 2017, 20:54 Короче, всё решается в зависимости только от типа. Скукатень. А где здесь развесистые switch'и? :)Название: Re: Нетипичное наследование Отправлено: sergek от Октябрь 12, 2017, 20:55 А чем это лучше auto & ? При чем тут лучше/хуже? Если нет цели изменить содержимое m_arr, зачем нужно создавать ссылку на элемент контейнера? Так что в данном случае просто auto будет достаточно.ps. прошу прощения за офтоп. Название: Re: Нетипичное наследование Отправлено: m_ax от Октябрь 12, 2017, 21:04 Цитировать Так что в данном случае просто auto будет достаточно. Нет, не всегда.. Если нет копирующего конструктора, определённого пользователем, то будет вызван конструктор по умолчанию (поправьте, если не так), что может быть затратно..Цитировать Скукатень. А где здесь развесистые switch'и? :) Это да - не канонично ;DНазвание: Re: Нетипичное наследование Отправлено: Авварон от Октябрь 12, 2017, 23:08 auto&& - это т.н. "универсальная ссылка", которая биндится либо к T&, либо к T&& в зависимости от того, что стоит справа от = (т.е. в случае цикла, что возвращает operator* итератора).
Основной юзкейз использования - если предполагается делать std::forward. Т.е., например, можно сделать итератор, который будет мувать элементы из контейнера, если контейнер - временный объект (перегрузить begin()&& и end)&&). На практике такое, конечно же, не всречается, даже разрабы стандарта не столь упороты. Минусом у auto&& является то, что она теряет константность, если контейнер в for-е неконстантный, а итератор возвращает ссылку. Самое смешное, что тут поможет qAsConst, который сделан, чтобы залечить проблемы implicit sharing. Название: Re: Нетипичное наследование Отправлено: Igors от Октябрь 13, 2017, 12:04 Да, именно так. Это тот самый случай, когда необходимо разруливать (развлетвлять) поведение системы в зависимости только от пренадлежности её к определённому типу, минуя необходимость создавать объект класса.. Это классический паттерн класс харрактеристик (type traits). И да, он работает (и как это видно из контекста) в тех случаях, когда "checkCommand не обязан иметь внутренние данные команды чтобы он мог что-то решать." :) Короче, всё решается в зависимости только от типа. Очень сомневаюсь что на голом типе/статиках можно много решитьНет, не всегда.. Если нет копирующего конструктора, определённого пользователем, то будет вызван конструктор по умолчанию (поправьте, если не так), что может быть затратно.. Конструктор копирования по умолчанию, который автоматычно вызывает конструкторы копирования для всех членов.А все-таки как охотно подхватывается любой "синтаксический сахар" :) До самой задачи дела никому нет, главное - чтобы написано было круто. А еще говорят что погоня за модой - чисто женская черта :) Название: Re: Нетипичное наследование Отправлено: Old от Октябрь 13, 2017, 12:09 А все-таки как охотно подхватывается любой "синтаксический сахар" :) До самой задачи дела никому нет, главное - чтобы написано было круто. А еще говорят что погоня за модой - чисто женская черта :) :)Как раз задачу мы и решали, в отличие от вас. :) Мы добились того, что необходимые флаги для каждой команды можно описывать при создании новой команды и проверять их без создания экземпляра команды. Если в дальнейшем, для принятия решения, понадобится экземпляр класса задачи, его всегда можно создать. |