Разбор ООП с Delphinum

# Delphinum (29.11.2016 / 19:24)
да и зачем может быть нужна коллекция сервисов?

Ну вот и я не понимаю зачем, в любом случае можно сделать как-то так:

$container->bind('services')->toFactory(function ($container) {
    return [$container->get(A::class), $container->get(B::class)];
});

# Delphinum (29.11.2016 / 19:24)
По поводу родительского и дочернего контейнеров не могу представить прикладное применение этого. Не сталкивался на практике с подобным, но это легко реализуемо для любого контейнера с абстрактными фаб

Ну вот я нашел пример, правда на Java: http://picocontainer.com/scopes.html.
Что б было понятно о чем речь. Вот зачем такое вообще делать?

L!MP, видимо просто какая то плюшка "чтобы была". Я еще не сталкивался с необходимостью получения нескольких сервисов коллекцией. Да и это не безопасно с семантической точки зрения, кто знает какие сервисы входят в эту коллекцию?!

# Delphinum (29.11.2016 / 19:24)
Нет, тегами в этом смысле я не пользуюсь. Контейнер всегда возвращает мне конкретный сервис, а не их коллекцию, да и зачем может быть нужна коллекция сервисов? Можно ведь сразу в контейнер поместить а

я того же мнения, вот сидел, думал, так и не смог придумать, куда применить...
Хотя может просто разработчики не дали хорошего примера.

# L!MP (29.11.2016 / 19:36)
Ну вот я нашел пример, правда на Java: http://picocontainer.com/scopes.html.
Что б было понятно о чем речь. Вот зачем такое вообще делать?

Может это применимо для переопределения содержимого контейнера в системе с модульной архитектурой? На пример, чтобы дать конкретному модулю возможность переопределить конкретный сервис для своих нужд. Так, мой модуль сможет использовать какой нить отличный от стандартного логгер или кеш, правда не вижу в этом смысла, так как моему модулю не важно, куда система пишет лог или через что кеширует, ему важно лишь наличие этих сервисов.

# Delphinum (29.11.2016 / 19:40)
Может это применимо для переопределения содержимого контейнера в системе с модульной архитектурой? На пример, чтобы дать конкретному модулю возможность переопределить конкретный сервис для своих нужд.

Ладно, в этом есть логика хотя я не представляю подобную архитектуру где б это было критичным требованием.
В любом случае можно дать такому сервису другой экземпляр контейнера. Не так удобно конечно выйдет, но результат тот же.

Ещё вот вопрос по типам биндингов.
Может есть ещё какие-то юзкейсы. Я пока вижу это так:

// биндинг абстрактного типа к константному значению
$container->bind(FooInterface::class)
    ->toConstant(new Foo());
// биндинг абстрактного типа к конкретной реализации
$container->bind(FooInterface::class)
    ->to(Foo::class);
// биндинг конкретной реализации к себе самой
$container->bind(Foo::class)
    ->toSelf();
// альяс к существующему биндингу
$container->bind(FooInterface::class)
    ->toAlias(Foo::class);
// биндинг абстрактного типа к фабрике, в качестве фабрики любой callable
$container->bind(FooInterface::class)
    ->toFactory(function () {
        return new Foo();
    });

# L!MP (29.11.2016 / 20:08)
Ещё вот вопрос по типам биндингов.
Может есть ещё какие-то юзкейсы. Я пока вижу это так:


// биндинг абстрактного типа к константному значению
$container->bind(FooInterface::class)
->toCons

Все вышеперечисленное лучше свести к двум "биндингам":
1. Интерфейс к константе или классу, реализующему этот интерфейс
2. Интерфейс к фабрике, сервис которой реализует этот интерфейс

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

Delphinum,

От всего остального потихоньку отказываются.

А что там остальное. Класс к самому себе то же нужная вещь.
В любом случае оно есть не просит, пусть будет.

# L!MP (29.11.2016 / 20:23)
Delphinum,
А что там остальное. Класс к самому себе то же нужная вещь.
В любом случае оно есть не просит, пусть будет.

Остальное это класс к себе и имена не соответствующие именам классов или интерфейсов. Очень редко применение таких имен необходимо и оправданно.