Вопрос по ООП синтаксис

[MiksIr]

Знаю, например использование непубличных классов в пакете.
Если считать, что пользователь не будет нарушать базовых принципов работы с фреймворком, то таких способов уже много, а если нарушит, то прекрасно понимает для чего.

Еще раз, предлагаю различать Синглтон и синглтон (с) http://misko.hevery.com/2008/08/25/root-cause-of-singletons/

 

[MiksIr]

И чем это так уж прям отличается от $this->doctrine = Container::get('doctrine') в конструкторе?

Имхо, тем, что класс не тянет зависимость от какого-то "Container", да еще провоцирует написать так не в конструкторе, а когда-то где-то потом.

 

[MiksIr]

Это сильная связанность, прямая зависимость. Это SL, а не DI.

А если будет @Inject("DoctrineInterface") - все внезапно изменится?

 

[fixxxer]

В случае с Doctrine\ORM\EntityManager прямая зависимость будет в любом случае.
Мне очень сомнительна возможность заменить его на что-то другое без переписывания использующего его кода, хоть обвешайся интерфейсами.

Другое дело, что если все, что от него надо - это, скажем, getRepository(), тогда можно какой-нибудь RepositoryProviderInterface, угу.

(Вообще вот смотрю я на этот EntityManager и как-то там все в кучку, какой-то getEverything.)

 

[hell0w0rd]

fixxxer, EntityManager - это вообще отдельная песня. Это самый настоящий God-Object, причем он сам себя почти во все зависимости передает.

 

[grigori]

аннотация вместо непосредственной инициализации в конструкторе нужна чтобы защитить разработчика от самого себя,
иначе дебил сделает инициализацию в деструкторе

 

[Absinthe]

А если будет @Inject("DoctrineInterface") - все внезапно изменится?

Это прямой запрос определенного объекта из кода. Ничем не отличается от SL::get('DoctrineInterface'), просто другой синтаксис запроса. Зависимость от контейнера присутствует в обоих видах написания.
В DI запросов быть не должно, нужные объекты попадают в класс внешним способом, а не по запросу этого класса.

Еще раз, предлагаю различать Синглтон и синглтон (с) http://misko.hevery.com/2008/08/25/root-cause-of-singletons/

Прочитал, и?
Я согласен с твоим прошлым определением синглтона, и поэтому в Ларавеле фасады - это синглтоны.

 

[Вурдалак]

Absinthe, справедливости ради, это никакой не запрос, а конфигурация на уровне аннотаций. Отличает то, что, например, unit-тесты будут чистыми.

 

[Absinthe]

Absinthe, справедливости ради, это никакой не запрос, а конфигурация на уровне аннотаций. Отличает то, что, например, unit-тесты будут чистыми.

То, что этот элемент синтаксиса можно не подключать, - уже другой вопрос
Но не согласен с тем, что это не запрос.

 

[MiksIr]

В DI запросов быть не должно, нужные объекты попадают в класс внешним способом, а не по запросу этого класса..

Отлично, т.е. @Inject("DoctrineInterface") - это запрос, а __construct(DoctrineInterface $doctrine) - это DI?
И в чем же принципиальная разница?

 

[Absinthe]

Отлично, т.е. @Inject("DoctrineInterface") - это запрос, а __construct(DoctrineInterface $doctrine) - это DI?
И в чем же принципиальная разница?

SL vs. DI.

 

[fixxxer]

MiksIr, если у тебя 10 параметров в конструкторе, то ты сразу видишь, что написал ерунду. А с @Inject-ами выглядит вроде и ничего.

 

[WMix]

MiksIr, если у тебя 10 параметров в конструкторе, то ты сразу видишь, что написал ерунду. А с @Inject-ами выглядит вроде и ничего.

 

[cDLEON]

MiksIr, если у тебя 10 параметров в конструкторе, то ты сразу видишь, что написал ерунду. А с @Inject-ами выглядит вроде и ничего.

Если у тебя 10 параметров в конструкторе - обратись к психологу. Твоя логика дала сбой.
А заменив говнокод inject-ами ни чего не поменяется. Просто получится говнокод из инжектов. Сами инжекты в виде комментов - уже говнокод.

 

[Вурдалак]

Absinthe, а вот если говорить про этот пример:

/**
* @DI\InjectParams({
*    "em" = @DI\Inject("doctrine.orm.entity_manager"),
*    "session" = @DI\Inject("session")
* })
*/
public function __construct($em, $session)
{
    $this->em = $em;
    $this->session = $session;
}

— тут ты тоже называешь эти аннотации запросом?

Если у тебя 10 параметров в конструкторе - обратись к психологу. Твоя логика дала сбой.
А заменив говнокод inject-ами ни чего не поменяется. Просто получится говнокод из инжектов. Сами инжекты в виде комментов - уже говнокод.

КО спешит на помощь, он говорит, что при прямой инъекции в property проблема будет замечена позже, поэтому прямая инъекция в property — зло. Собственно, с setter injection та же проблема, многие чуваки используют setter injection «патаму шта конструктор может быть перегружен аргументами!!11» и «решают» проблему неправильно.

 

[Absinthe]

Вурдалак, примерно как-то так это выглядит при подключенных аннотациях:

public function __construct()
{
    $this->em = Yii::app()->db;
    $this->session = Yii::app()->session;
}

 

[Вурдалак]

Absinthe, что это значит? Это компилируется абсолютно так же, как и при конфигурации из YAML-конфига: скомпилированный контейнер отличаться не будет. Это такой тип конфигурации. Если мету записал в комментарий — это запрос, а если мету спихнул в YAML или XML, то это уже не запрос? Где тут логика? И да, это именно DI. Зависимости инжектятся, breaking news.

Я не защищаю аннотации, но мне такие аргументы не нравятся.

 

[Absinthe]

Вурдалак, почему ты не рассматриваешь аннотации как часть синтаксиса?

Если мету записал в комментарий — это запрос, а если мету спихнул в YAML или XML, то это уже не запрос?

Если код сам требует зависимости - это запрос, если код не требует зависимости - не запрос.

 

[Вурдалак]

Вурдалак, почему ты не рассматриваешь аннотации как часть синтаксиса?

Это такой синтаксис конфигурации, ага.

Тебе станет легче, если глагол «Inject» заменить на существительное?

/**
* @DI\Arguments({
*    "em" = @DI\Argument("doctrine.orm.entity_manager"),
*    "session" = @DI\Argument("session")
* })
*/
public function __construct(EntityManager $em, SessionInterface $session)
{
    $this->em = $em;
    $this->session = $session;
}

Если код сам требует зависимости - это запрос, если код не требует зависимости - не запрос.

Требования аргументов в конструкторе — это уже требование зависимостей. Если их не передать, то код работать, увы, не будет.

 

[Absinthe]

Вурдалак, дело в самом наличии в коде запрашиваемых сервисов (по их идентификаторам). А когда сервисы звпрашиваются откуда-то, это SL