У меня есть компонент 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, вы можете иметь свободные функции и глобальное состояние вне классов, совершенно скрытые от посторонних глаз, если только не запрашивается внешняя связь. Преимущество этого способа - более легкая расширяемость, и если вам не нужно предоставлять специфический интерфейс (для статической инъекции с шаблонами или динамической инъекции с наследованием), то недостатков нет.
На самом деле это предпочтительный способ, нет причин поступать иначе.