Pull to refresh
115
0
Никита Цуканов @kekekeks

Гуру велосипедостроения

Send message
Ну не знаю, Windsor, Autofac и Ninject это в состоянии делать, с другими DI-контейнерами, я, увы, не работал.
что при использовании service locator мы завязываемся на конкретную имплементацию сервиса
Нет, не завязываемся, лишь на «интерфейс», который в php достигается утиной типизацией. Строго говоря в статье Pimple используется для Dependency Injection (зависимости всё же приходят через конструктор, а не заполняются в нём через $locator['service']), но сам по себе реализует именно Service Locator, так как представляет собой банальный реестр и не способен самостоятельно создавать инстансы.
Компонент должен быть простым в использовании, а не в реализации, нет?
В моём понимании «полноценный DI-контейнер» — это когда мы говорим контейнеру какому интерфейсу что соответствует, просим создать нужный объект, а со всем остальным он думает без нашего участия. А тут надо во-первых дублировать кучу кода (когда вам надо что-то заинжектить в несколько разных классов), во-вторых помнить, где какие параметры у конструкторов. Неудобно, многословно, тратит время.
Ну я не спорю с тем, что применяется именно DI (при «деревянном» использовании локатора классы сами его пинают из конструктора, а локатор представляет из себя статический класс/лежит в глобальной переменной), просто указанный контейнер не является DI-контейнером в полной мере.

Я глянул доку по PHP, там вроде есть какой-то Reflection. Его точно никак нельзя применить для реализации полноценного DI-контейнера?
Ну вот если посмотреть на DI из мира языков с поддержкой reflection, то можно заметить, что они ощутимо иначе работают.

Предположим, у нас есть вот такой набор классов:
class FooImpl : IFoo
{
    Foo(IBar dependency){}
}
class BarImpl : IBar
{
}
class Target
{
    Target(IFoo dependency)
}


В случае с DI мы делаем примерно так
//Тут привязки в произвольном порядке
container.Bind<IFoo>().To<FooImpl>();
container.Bind<IBar>().To<BarImpl>().InSingletonScope();
//Просим контейнер создать экземпляр класса, имеющего зависимости.
container.Resolve<Target>();

Теперь посмотрим на код с использованием паттерна Service Locator:
locator.Set<IBar>(new BarImpl());
locator.Set<IFoo>(()=> new FooImpl(locator.Get<IBar>());
new Target(locator.Get<IFoo>());

Очень похож на ваш, правда?
У нас появилась необходимость вручную обращаться к локатору за зависимостями при конструировании объектов, а так же необходимость знать, какие зависимости нужны каждому сервису. Это отличительные черты паттерна Service Locator (которому для работы не нужна поддержка вывода информации о типах со стороны языка), из чего я делаю вывод, что в вашем коде используется именно он.
В регионах вообще общий уровень зарплат раза в три меньше, не вижу ничего удивительного. Если кому-то не готовы нормально платить там, где он живёт, значит, надо переехать туда, где платить будут. Жаловаться на «всё плохо, бесперспективность, безысходность» можно, конечно, но никаких перемен не привнесёт.
Ну вы это вручную делаете на этапе конфигурации. То есть классический Service Locator. DI-контейнер же должен сам разбираться, кому какие аргументы конструктора вбить.
Это на любом рынке высококвалифицированной рабочей силы проявляется. Действительно хороших спецов всегда меньше чем потребность в них.
Или я чего-то не понимаю, или получение сервисов через container['service'] — это паттерн под названием Service Locator, но никак не DI.
Специалиста (если он не в доле) не должно интересовать, откуда берут его зарплату. Если работодатель не в состоянии оплачивать его услуги, есть множество других, которые в состоянии. Это рынок.
Плохое это слово «зажрались». Оно переводится как «им хорошо, мне плохо, надо чтобы им тоже было плохо». Отчего у народа нашего такое отношение к чужому благополучию для меня является загадкой.
первым параметром вам передастся указатель на инстанс
int _ZN9Testclass6getvarEv(int instance) {
int instance
int
указатель
Не надо так, есть же apt-get clean.
Извращение какое-то. Описываемая проблема «двух проектов» решается вот так:
public static void Main (string[] args)
{
	if (args.Length != 0 && args[0] == "second")
		Thread.Sleep(1000);
	else
	{
		var proc = Process.Start(typeof (Program).Assembly.GetModules()[0].FullyQualifiedName, "second");
		proc.WaitForExit(500);
		Thread.Sleep(1000);
		proc.Kill();
	}
}
Попадите из входа, отмеченного стрелочкой к выходу, отмеченному стрелочкой, следуя правилу одной руки.
Что значит «как попадёте»? Если вы уже не в лабиринте, то и выходить из него не надо, никакие алгоритмы не нужны. Если вы уже в лабиринте, то вы можете быть в абсолютно любой точке. Если алгоритм не работает для любой точки из которой возможно попасть в искомую, это означает, что он не работает вообще.
Ок, выберитесь из центральной области следуя правилу одной руки, если вам от этого будет легче.
Если вы уже находитесь в этой недостижимой области, то выход для вас будет так же недостижим. Выберитесь из центральной области лабиринта на картинке выше.
imageПопадите в центральную область.

Information

Rating
4,357-th
Location
Москва, Москва и Московская обл., Россия
Registered
Activity