Русский
Русский
English
Статистика
Реклама

Вычисление динамических объектов по вектору

Введение

Допустим, у нас есть набор объектов с некими данными, и нам нужно произвести манипуляции с этими объектами.

Положим, самый обычный пример - наполнить корзинку фруктами. Мы реализуем некий класс Сart, в который будем складывать фрукты. Далее нам понадобиться базовый класс Fruit, для того, чтоб определить параметр объема, которому мы будем присваивать значение в зависимости от фрукта. Задача решена, фрукты складываются до тех пор, пока объем корзинки не достигнет порога.

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

И вот тут начинается проблема. Да, наш класс стал более универсальным, но увеличиваться может не только количество проблем с фруктами, но и сами ситуации сбора фруктов могут быть различными. Например, мы собираем фрукты там, где абсолютно каждый плод будет свежим. Зачем, в таком случае, нам поле, отвечающее за свежесть, если все фрукты заведомо свежие? Городить лишний функционал, для указания обязательных и не обязательных типов? - нет конечно. Мы выносим ряд опциональных типов в массив(словарь), где каждый тип не является непосредственной частью класса. Наш функционал снова стал умнее, отлично.

Однако, я решил пойти дальше, и немного развить эту тему.

Идея

Мы определяем тип, который будет отвечать за хранение опциональных переменных в строковом формате. Фактически, это обертка над массивом. В качестве минимального набора информации будем хранить название переменной, тип(это может быть как базовый, int, string, bool, так и композиция из нескольких базовых) и значение.

Методы у данного объекта могут быть вариативными, но я для себя выделил следующие:

  • получение списка переменных и их типов в строковом формате(в целом, можно ограничиться названиями). Это может пригодится если мы какой-то объект захотим отметить "началом координат".

  • геттер, который возвращает наш массив с информацией о переменных в формате константы.

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

class IVariable{public:using Type = std::variant < int, double, bool, std::string>; // для удобства каста типов  virtual std::vector < std::pair < std::string_view, std::string_view > > abstract() = 0;  virtual std::vector < std::tuple < std::string_view, VarTypes, std::string_view > > released() = 0;virtual std::pair < VarTypes, std::string_view > released(const std::string_view& name) = 0;    };

Теперь, когда у нас все опциональные параметры обособлены в отдельный тип, мы можем проделать следующее:

  • Имея набор все тех же фруктов, проверить параметр "свежесть" у каждого фрукта, предварительно построив вектор только из этого параметра.

Вспомогательная функция, которая просто проверяет наличие конкретного параметра у массива наших "расширенных" переменных

bool tryVector(const std::string_view& dX){auto type = range.front()->released(dX); if(type.first == VarTypes::_null) {    return false;}for(auto&& var : _range){if(var->released(dX).first != type.first)  {return false;}}return true;  }
  • Или наоборот, построить вектор сразу из нескольких параметров(скомбинировать несколько вызовов tryVector).

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

Мотивация

  • Возможность оперировать с данными набора объектов, не имея информации о базовом типе, или вообще не имея базового типа.

  • Возможность регулировать скоуп работы с объектами, когда, в зависимости от ситуации, нам нужно либо больше параметров, либо наоборот меньше.

  • Думать не над тем, как спроектировать объект, а над тем, какие действия должны совершаться с объектом

Недостатки

  • Не подходит для расчета большого количества однотипных объектов. Скажем, для какого-нибудь класса, определяющего rgb составляющую пикселя - эффективнее будет явно определить свойства.

  • Подобный подход будет потреблять достаточно много памяти, и соответственно имеет смысл использовать его только для работы с объектами, суть которых нельзя выразить через несколько простых переменных, т.е. больше для логической обработки объектов, нежели прямых расчетов.

Источник: habr.com
К списку статей
Опубликовано: 08.03.2021 00:05:56
0

Сейчас читают

Комментариев (0)
Имя
Электронная почта

C++

Алгоритмы

Ооп

Программирование

Поток данных

Унификация

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru