?

Log in

No account? Create an account
Main

Хотел ответить на комментарий к моему посту про DI, но в размер не уложился. Поэтому отвечу постингом.

Комментарий ezdakimak:

Вообще я не люблю Push метод передачи объектов. У меня преобладает Pull по типу

<?php
public function __construct(){
  
$this->db=CMS()->DB()->getDB();
}

Насчет push-pull. Для соединения с БД и подобного рода "звездных" объектов разумно устраивать такой Registry или Service Locator. В симфони подобный вашему CMS классу класс называется Context. Но часто нужны более "локальные объекты" и пихать их в контекст как-то странно и неуклюже.

Например у меня есть класс Report, который рендерит sql запрос ну и наследники, которые рендерят список объектов, обращаясь к модели. И вот такому классу было разумно пушить внутрь ReportFilter — объект, который устраивает разные виды отчетов — зебра, многоколоночный, вывод ячеек в порядке Z или в порядке N, таблица со "стертыми" границами и т.д.

<?php
$myReport
= new colesoDBReportLite(dirname(__FILE__).'/flat_column_template.tset.phtml');
 
$flatColumnFilter= new colesoFlatColumnOutputFilter();
$flatColumnFilter->outputType='Z'//вывод слева направо и сверху вниз
$flatColumnFilter->setColumns(5);
 
$myReport->setOutputFilter($flatColumnFilter);
$html2=$myReport->renderSQL($sql);
Но такой способо малость громоздкий. Теперь с помощью контейнера DI я смогу сильно сократить этот код. Просто запросив
<?php
$rc
=new ReportContainer(array(
  
'filter.type' => 'FlatColumn',
  
'filter.outputType' => 'Z',
  
'filter.columns'    => '5',
  
'report.template' => 'pathToTemplate'
));

$report=$rc->getRender($sql);

Таким образом я прячу зависимости report от filter в конфигиурацию контейнера. И получаю некоторую свободу.

Я пожалуй переведу страничку от доки к Phemto — DI контейнеру от Маркуса Бэйкера, который сделал SimpleTest. Там немножко под другим углом и библиотека совсем миниатюрная. Взгляни на нее, только не на ту доку, что на сайте, а на ту, что внутри дистрибутива.

Comments

3. Тем, что объект-посредник берет на себя управление зависимостями мижду классами. И это управление не хардкодится, а конфигурируется так или иначе. В результате в классах не надо думать о промежуточных настройках, параметрах конструктора и т.п. с одной стороны, и мы легко можем в эти зависимости влезть не затрагивая код с друой стороны.

а фабрика зависимостями не рулит. Она просто выдает объект по запросу. Наверное можно это воспринимать как конфигурируемую фабрику.

Edited at 2009-07-10 05:43 am (UTC)