Обострение DIC vs ServiceLocator

Redjik

Джедай-мастер
Знаю, ну лень псведокод дотачивать уже =)
Там же проверка на сабмит идет.
 

Redjik

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

Вурдалак

Продвинутый новичок
Исправил вброс, не продумал изначально, крепко задумался про tell dont ask и DIC
На самом деле все зависит от ситуации, просто до меня наконец дошло в чем разница и как делать "кошерный" Tell Dont Ask везде
Если по поводу теории, то TDA с сабжем вообще никак не соприкасаются.
 

Redjik

Джедай-мастер
Эм, устраняется главный резонанс.

We ASK container to give us a mailer object. Then we TELL the mailer object to send email. (SL)
On the other hand.
We have a mailer object and TELL that bastard to send email. (DIC)

Очевидно же. =)
Выстроить остальное по TDA, уже проще, хоть пример и не полностью соотвествует.
 

Вурдалак

Продвинутый новичок
Нет, в TDA «tell» и «ask» в отношении одного и того же объекта. Ну, например, если ты пишешь
PHP:
if ($this->mailer->isValidMail($mail)) {
    $this->mailer->send($mail);
}
— это нарушение TDA. Лучше, если send() выкидывает InvalidMailException.
 

Redjik

Джедай-мастер
А, ну да, но в отношении одного и того же обьекта - контроллер просит контейнер дать ему мейлер vs контенер говорит контроллеру, вот тебе мейлер - юзай.
 

fixxxer

К.О.
Партнер клуба
Нет, в TDA «tell» и «ask» в отношении одного и того же объекта.
Необязательно. Еще это касается объекта-посредника (скажем, контроллер в MVC), который вместо того, чтобы передать один объект другому, спрашивает у одного его свойства и передает их значения другому (притом ему знания о наличии этих полей в хрен не впились). типичный пример - когда в контроллере вместо $view->assign('User', $userModel) пишется $view->assign(['email' => $userModel->email, 'name' => $userModel->name....]).
 

fixxxer

К.О.
Партнер клуба
хехе. Этот пример в контексте веб-разработки первым в голову приходит, ога.
 
Сверху