Adamos

Как именно я должен хранить данные конфига?!

Смотрите. У вас есть конфиг, есть классы, которым нужно получить данные этого конфига.
Как именно он хранится - эти классы не знают и знать не желают.
Потому что вы сделали класс конфига, у которого есть внешние функции "получить нужные данные" и внутренний механизм, который реально берет их оттуда, где они хранятся. Это же ООП.

Мне нужно сделать это через класс с ограничением видимости или как-то еще?

Да, внутренняя часть делается через ограничение protected / private

Если это будет класс, нужно ли в данном случае использовать конструктор?

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

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

Простейший пример - jQuery.cookies. Кукисы в браузере хранятся неудобно для редактирования, но это проблемы внутри черного ящика, снаружи их быть не должно. Снаружи вам надо поставить куку и прочитать куку. С коротким списком возможных свойств. Вот это класс и реализует, вполне успешно. Буквально одним методом.
Мог бы этот метод быть простой процедурой? Да, конечно. Но как раз это - неважно.

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

Нет, так делать не стоит.
Вы таким наследованием нарушаете L в SOLID.

class Str_Indef: public Stroka
{
public:
    using Stroka::Stroka;
}

При условии, что у вас компилируется С++11. До этого в С++ наследования конструкторов не было вовсе.