?

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

выложите на http://translated.by/ для перевода — там удобно, да и коммунити присутствует.
Ага. Спасибо за ссылку.
Ну тут несколько пунктов могу отметить.

1) Не выделяю "звездные классы". Тот объект принимает любые классы по типа addObject($name,$obj); И делает их доступными через __call(). Не выделяю потому, что не имею четких критериев для этого дела.

2) Мелкие объекты, конечно, я не использую так =) То есть то, что расшаривать не надо - там не хранится. Если они "локальные", но тем не менее расшариваемые, то подобные методы для пула имеются у родительских объектов.

3) Может я ещё не совсем въехал, но в чем по сути это отличается от той же фабрики? Только тем, что объект становится проксиком для переадресации созданному элементу?

4) push и pull это в принципе управление конфигурацией, что-ли. То есть у меня грубо говоря разделяются классы на "управляющие" и на "управляемые". Первые читают всякие конфигурации и задают настройки, а вторые только берут то, что для них подготовили. Стараюсь сделать минимум первых, чтобы сосредоточить логику работы приложения в минимальном количестве мест (в смысле операции типа в какой последовательности что загружать).

То есть в pull в одном месте задаются правила и на всех тут же распространяются. А на push нет.

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

5) Вообще на счет push и pull не вижу особой причины для спора. Если хочется использовать оба метода, то нет ничего проще написать простой конструктор типа
__construct($options){
foreach($options as $service=>$object){
$this->$service=$object;
}
}
3. Тем, что объект-посредник берет на себя управление зависимостями мижду классами. И это управление не хардкодится, а конфигурируется так или иначе. В результате в классах не надо думать о промежуточных настройках, параметрах конструктора и т.п. с одной стороны, и мы легко можем в эти зависимости влезть не затрагивая код с друой стороны.

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

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