Глобальные объекты против свободных функций C++?

Глобальные объекты против свободных функций C++?
Глобальные объекты против свободных функций C++?

У меня есть компонент C++, который содержит важные данные, необходимые различным другим компонентам в моей программе.

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

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

Например:
We есть компонент options, который содержит некоторые опции/конфигурации для других компонентов.
.

Некоторые опции могут быть не нужны от одного компонента.

Вопрос в том, должен ли модуль options быть классом и сделать его публичным с помощью ключевого слова extern в заголовочном файле или просто использовать обычные свободные функции (getters)?

Если options является объектом. Это будет только один объект. Нет необходимости в создании второго объекта. Поэтому это будет либо синглтон, либо просто публичный объект в файле cpp, переданный глобально с ключевым словом extern в заголовке.

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

Класс:

class options
{
  int getOption1();
  int getOption2();
  char getOption3();
  float getOption4();
  char * getOption5();
}

Свободные функции:

namespace options
{
    int getOption1();
    int getOption2();
    char getOption3();
    float getOption4();
    char * getOption5();
}

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

Во-первых, зачем вам нужен синглтон?

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

Далее, зачем вообще нужен класс?

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

На самом деле это предпочтительный способ, нет причин поступать иначе.


LetsCodeIt, 5 февраля 2023 г., 01:18