Konstantin

тут изначально очень не правильный подход. не нужно делать "дефолтную конфигурацию" через глобальные переменные.

class DbConnection
{
    private string $userName;
    private string $password;
    private string $dbname;

    public function __construct(string $userName, string $password, string $dbName)
    {
        $this->userName = $userName;
        $this->password = $password;
        $this->dbname = $dbName;
    }
}


class AuthController
{
    private DbConnection $dbConnection;

    public function __construct(DbConnection $connection)
    {
        $this->dbConnection = $connection;
    }
}

$dbSettings = include('dbconfig.php');
$connection = new DbConnection($dbSettings['login'], $dbSettings['password'], $dbSettings['dbName'] );
$controller = new AuthController($connection);

а в файле dbconfig.php

return [
'login'=>'myLogin',
'password'=>'myPassword',
'dbName'=>'myDbName'
];

phpStorm + docker, в современном мире отпала необходимость в сборках (типа xampp или denver), все прекрасно заводится и переносится в docker, очень приближенно к production окружению

Мне самому был бы интересен ответ на вопрос.
Мысли вслух: Если сделать readonly объект и позволить его сетить только через конструктор, будет ли удобно это делать для больших объектов. Описывать конструктор который принимает 50 аргументов?
может быть можно сделать доступ к аргументам через магический метод __get и аннотации, а сетить уже через сеттеры, билдером, например.
Лично я параноиться по поводу ридонли я бы не стал, т.к. Если кто-то захочет изменить объект, он его изменит , рефлексию никто не отменял. Это скорее должно работать на уровне договоренностей.
Но это только мое мнение, не претендую на истину.

все скобочки пересчитайте в if ;)

Как сказал коллега выше - преждевременная оптимизация - корень всех зол. Вопрос не в языке и не в фреймворке. Каждый из современных языков и фреймворков можно оптимизировать. Возьмите то, с чем вы будете испытывать меньше трудностей. Можно ведь пилить бесконечно идеальный продукт, и никогда его не выпустить. Fail fast, fail cheap.
Оптимизацией лучше заниматься тогда, когда возникает в этом необходимость и там, где возникнет эта необходимость. Пилить сразу большой проект на чистом GO, я думаю будет очень сложно человеку, не знакомому с языком, и возможно не знакомому с инфраструктурой микросервисов. Go это ведь не только синтаксис. Да и даже в больших проектах на GO выносят только отдельные микросервисы, требующие оптимизации. (*так по крайней мере было на моей практике).
за 8к вы точно не найдете достаточно программистов чтобы пилить приложение на go-микросервисах, k8s эксперта который правильно будет деплоить и поддерживать k8s инфраструктуру вместе с ci-cd. А если всем заниматься самому, то хорошего из этого ничего не выйдет, глаз начнет дергаться.

Точно такой же вопрос возникал неоднократно и у меня с коллегами. Кто-то за то, чтобы при каждой выборке из бд, (в случае когда работаешь с массивами, а не объектами) нужно проверять наличие полей, у меня это вызывает недопонимание.
ИМХО правил тут не может быть, нужно подходить с точки зрения благоразумности. И да, лучше использовать DTO по возможности.