Добрый день!
Прошу порщения, если не в тот раздел.



И вот конкретная ситуация:

есть некий класс API:



и используется он так:


И где нибудь в модуле/подсистеме:


То есть API - это некое хранилище, посредник к другим независимым объектам, не хранящий в себе ничего, кроме ссылок.

Будут ли сложности при поддержке такого кода?
Лично для меня - это хорошее решение, все изменения других классов никак не повлияют на API, и никаких изменений в него писать не надо. Например, если мы изменим MSSQL на MySQL - максимум, это в методе initDB указать другой класс работы в бд, при этом будет полная совместимость всего кода, работающего через API.DB (есть четкое описание API-методов для всех классов: user, db, cache, route... и они обязаны ему соответствовать).

Так вот, плохо это, или хорошо?
Лично я описание анти-паттерна понял очень буквально: "в одном объекте хранится вообще все и все методы", в нашем же случае - это не так.
Является ли вышеописанная реализация антипаттерном?

Спасибо!

Очень хороший подход! Об этом я говорю на своей страничке "http://reforma-os.webnode.ru/".....
Сама по себе монолитность - это консерватизм, что не дает быстро развиваться новым идеям, потому что надо будет переписывать весь код,
а это не малые затраты.... Я ищу людей заинтересовваных в развиитии проекта, который у меня есть, начинать можно с малого,
заработать можно не плохо будет....

Описанная реализация не является антипаттерном, зато является паттерном. И именуется он Фасад (Facade).

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

А вот юзать глоабальные переменные - вот это хреновая практика, попробуйте юзать паттерн сингильтон.