Как мне разделить тестовые значения?

Question

В настоящее время я работаю над программой на Qt / C ++, которая будет анализировать и тестировать значения разностей, полученные от устройства под названием "Phabrix SxE". Эти значения будут иметь разные ограничения в зависимости от того, какой продукт мы тестируем.

Моей первой мыслью было создание класса с именем что-то вроде «TestLimits» с закрытыми переменными для всех значений, которые мы будем тестировать. Затем этот класс будет использоваться в классе i, называемом «TestConfiguration» (который, помимо класса «TestLimits», будет содержать информацию о том, какой IP-адрес, порт и имя у устройства Phabrix).

TestConfiguration (name, ip, port, limits);

Если я использую эту стратегию, мне нужно будет использовать геттеры и сеттеры для каждого частного значения в классе TestLimits. Я не настоящий поклонник геттеров / сеттеров, просто потому что они нарушают инкапсуляцию. Если я вместо этого использую только класс "TestConfiguration" и объявляю все ограничения прямо в параметрах конструктора ...

TestConfiguration (name, ip, port, limit1, limit2, limit3, ..., ...);

... было бы очень быстро запутаться.

Как можно избежать методов получения, установки и длинных, грязных конструкторов при создании чего-то подобного? Даже если я использую «TestLimit», мне нужно объявить их следующим образом ...

TestLimit(limit1, limit2, limit3, ..., ..., ...);

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

Кто-нибудь делал что-то подобное и может дать мне несколько советов?

Спасибо!

Answer 1

Лучший ответ для вашей ситуации зависит от целей разработки остальной части программного обеспечения. Некоторые примеры вопросов, которые я бы использовал для выбора вариантов дизайна:

• Сколько лимитов, и они все одинакового типа или разные?
• Как их называют? То есть они буквально "предел 1, предел 2, ..." или "максимальное напряжение, максимальный ток, ...?"
• Часто ли меняется количество или схема лимитов? Это что-то маленькое сейчас, но может масштабироваться по мере развития программы?
• Как программное обеспечение узнает, каковы ограничения? Они приходят из файла конфигурации, диалогового окна пользователя, жестко запрограммированы или что-то еще?

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

---

Вариант 1: Обычная старая структура

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

struct TestLimits {
    voltage max_voltage;
    current max_current;
    limit limit3;
};

Это позволяет вам ссылаться на каждое ограничение по значимому имени в исходном коде и устраняет все утомительные коды конструктора, геттера и сеттера. Возможно, будет сложнее сделать ограничения более сложными позже. Например, если позже в программу добавлен новый тест, так что max_voltage теперь является функцией test_time, то все, что касается TestLimits, должно измениться.

Вариант 2: есть только геттеры для сохранения инкапсуляции

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

class TestLimitsFinder {
public:
    TestLimitsFinder();

    void find_all_the_limits();

    const voltage& max_voltage() const;
    const current& max_current() const;
    limit limit3() const;

private:
    voltage max_voltage_;
    current max_current_;
    limit limit3_;
};

Эта система предлагает некоторую инкапсуляцию. Единственный способ установить ограничения - это метод find_all_the_limits(). Это устраняет шаблонные конструкторы и установщики, но не геттеры. Если существует много объектов, которые используют ограничения, но только один или несколько, которые создают ограничения, то методы получения могут быть предложены как абстрактный ITestLimits интерфейс. Тогда все потребители ограничений не знают, как их находит программное обеспечение. Эта часть реализации может полностью измениться без изменения всех пользователей.

Вариант 3: QProperty

Qt имеет систему свойств , которая может быть весьма полезна для объектов, которые можно параметризировать. Если вы используете QProperties, становится очень легко создавать диалоги для получения свойств / ограничений, а также, помимо прочего, существует система сериализации XML. Свойства имеют большую гибкость с точки зрения того, писать ли пользовательские методы получения, установки и сигналы уведомления. Также возможно динамически добавлять или изменять свойства объекта во время выполнения.

С другой стороны, контейнер TestLimits должен быть производным от QObject, который представляет компилятор мета-объекта. Это вводит глубокие зависимости Qt в код ограничений, что может не подходить.