January, 2015 | Григорий Добряков

Есть два из трёх популярных видов ассоциаций: has_one и has_many. Все знаю как они устроены: в первом случае идентификатор связанной сущности является атрибутом модели (а следовательно – столбцом в БД). Во втором случае, создаётся транзитивная таблица связи со столбцами entityA_id и entityB_id.

Казалось бы, решения абсолютно равноправны, выбирай подходящее под задачу. Однако здесь есть важная проблема. Continue reading “No more has_one, please”

Многие из вас знакомы с паттернами снижения “сильносвязанности” кода программного продукта, такими как внедрение зависимостей. В качестве простого примера – объект класса Logger, который не указан явно, а подсовывается в ходе выполнения кода. В зависимости от задач, условий, текущего окружения и так далее – конфигурирование позволяет подсунуть в нужное место тот или иной логгер – и писать хоть в файлы, хоть в базу, хоть в очередь rabbitmq. Вам достаточно делать Logger.write(data), и дальше алгоритм конкретного внедрённого обработчика будет применён к указанным данным.

Однако мы все привыкли обманываться, считая имеющееся у нас “dependency injection” отличным способом понизить связанность. Да, мы убрали алгоритмы во внедряемые компоненты, но мы по-прежнему задаём их либо в коде, либо в аннотациях (в случае PHP/Symfony), либо в конфигурационных файлах окружения. И мне не давала покоя мысль – как отдать такое конфигурирование в руки клиенту (другими словами – сделать его управляемым “на ходу”), при этом не применяя костылирование и не изобретая велосипед. В этом посте я хочу поделиться с вами паттерном, решающим эту задачу, который мне почему-то не встретился в литературе, но его удалось наработать в ходе локальных экспериментов. Continue reading “Customer-driven dependency injection: отдаём поток выполнения программы в руки клиенту”