Pull to refresh

Comments 31

Ну в редакторе же есть тэг, code. А за перевод, спасибо!
он не подсвечивает, к сожалению.
кажется мне подсказали, как сделать. сейчас займусь.
highlight.hohli.com/ — вот здесь например, поставьте галочку для Хабрахабра и смело вставляйте то, что он сгенерит
Эти велосипеды ломают подсветку в кастомных темах, например. А всего навсего надо было использовать тег <source>

require_once('phemto/phemto.php'); 
 
$injector = new Phemto(); 
$injector->whenCreating('Page')->forVariable('session')->willUse(new Reused('Session')); 
$injector->whenCreating('Page')->forVariable('continuation')->willUse('Continuation'); 
$injector->whenCreating('Page')->forVariable('alerts')->willUse('Alert'); 
$injector->whenCreating('Page')->forVariable('accounts')->willUse('Accounts'); 
$injector->whenCreating('Page')->forVariable('mailer')->willUse('Mailer'); 
$injector->whenCreating('Page')->forVariable('clock')->willUse('Clock'); 
$injector->whenCreating('Page')->forVariable('request')->willUse('Request'); 
return $injector;


P.S. сорри за АП, статью привели как пример поломанной подсветки.
Минус. Причем самому паттерну.

Потому-что в процессе работы люди используют автозавершение по типам.

Именно поэтому в итоге на C# удобнее работать, нежели на нативном PHP.

Это я со временем понял и теперь на PHP все время использую только какой-нить Ecplise с завершением по типам.

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

Либо автор неудачные примеры привел.
Пожалуйста ответьте более развернуто.

Что такое завершение по типам, и как оно решает ту задачу, что описана в этой статье?

Как именно помогает Eclipse справиться с зависимостями между классами?
1. Завершение — это когда мы к примеру в сишарпе создаем объект:
Human petya = new Human();
// Потом пишем
petya.
// и нажимаем Ctrl + Space
// IDE выдает нам все методы и свойства класса Human

Аналогично в eclipse и прочих IDE.

2. Eclipse никак не помогает справится с зависимостями.
Я вообще не увидел здесь никакой проблемы.
Пожалуйста проблему почетче опишите.
Посмотрите пожалуйста примеры использования во второй части статьи, особенно вот этот:

— Пусть мы хотим написать реализацию Authentication на основе интерфейса фреймворка…
Наш компонент будет использовать общее с фреймворком подключение к БД, и еще мы хотим взять кэширующий компонент третьей стороны.
— на мой взгляд это потенциально трудное место весьма элегантно программируется с помощью этого паттерна.

я, в свою очередь, совсем не понял к чему тут автозавершение, которое дает IDE? Где паттерн мешает работе с методами и интерфейсами?
= По завершению =

$controller = $injector->create('MyController');

В ПХП это позволительно. Но потом каким образом указать IDE, что тип $controller — MyController?

Обычно это указывается в самом методе create, как @return {MyController}.

В СиШарпах и проч. можно сделать так:
MyController controller = ((MyController)injector->create('MyController'));

И далее работать с объектом.

В Eclipse по-мойму можно сделтаь так:
/**
* @type {MyController}
*/
$controller = $injector->create('MyController');

Но это опять же гемор, только сбоку.

Вторую часть читаю.
Про IDE понял. Мда. Но с другой стороны это получается ради IDE корячиться с кодом. Ну блин, а как же с полиморфизмом, т.е. возвращает тебе фабрика разные типы объектов с одинаковым интерфейсом? Ну наверное для жавы и сишарп IDE умеет это отследить… угу. Для PHP такого пока нет.

Хорошо, что я на это не подсел, хихик, хотя признаю, что удобно.
:) Для ПХП такое тоже по-мойму возможно:

/**
* @type {MyController}
*/
$controller = $injector->create('MyController');

С кодом не надо корячиться — надо сначала моделировать, а потом его генерить.

Всё.

Зато потом, когда проект начинает быть «пипец» каким большим, то весьма это помогает.

Исптытайте, тык скыть эффект масштаба.

А подсесть на это Вам придется со временем.

Напр., когда выйдет нормальная IDE, в которой это всё есть сразу, а не надо корячиться и собирать её.
>С кодом не надо корячиться — надо сначала моделировать, а потом его генерить.

оно конечно здорово, но код живет и развивается, все заранее не спроектируешь. Если бы так было, как Вы говорите, то рефакторинг нужен бы не был.
отвечает пользователь Eclipse(plug. PHPE)
@return datatype description
Неа, не получится.

Из того метода мы не знаем заранее, что вылезет.

Так что именно так для нормальных методов делают.

А здесь — ненормальный :)
Вообще, все проще:

/* @var $controller MyController */
$injector = new Phemto();
$controller = $injector->create('MyController');

Таким образом любая IDE (Zend, Zend for Eclipse точно) подцепят автодополнение и т.п.
код все-таки первичен ИМХО.
:) первична задача, которая оплачивается заказчиком.

А код — это всего лишь «один из».

И вообще по мне первичен не код, а его качество.

Это как бэ смещение акцентов:
«Деньги — не главное. Главное их количиство».

Так что работайте в этом направлении ещё усиленней. Либо набирайтесь опыта. Кароче это как бэ дзен. Оно пришло ко мне с неба :)
так я окачестве и говорю — не жертвовать же качеством ради IDE.

ну спасибо за дзен конечно.

просто как бы в статье дзен, но записанный в виде кода. A у Вас он какой-то непостижимый моим умом пока… :) Но дзен он да… он приходит.
Ничто не мешает сделать сервисный класс, знающий и отдающий нужные типы, а внутри использующий SC, IOC.
Как бэ вернулись к тому же, отчего якобы уходим?

Вообще этот подход уже начинает больше склоняться к аспект-ориентированному подходу, нежели, к объектно-ориентированному.

Причем я всё еще не улавливаю сути его?

Это типа для тех иррационалов, которые сначала делают, а потом думают???

Цель!!! Для каждого движения нужна цель.

Здесь я понимаю цель такая, чтобы вначале делать, а потом думать.
Только сейчас наткнулся на статью, так что откомменчу через 1.5 года только :-)

1. Для .net точно так же есть ninject/castle windsor.
2. Представьте себе задачу: у вас есть приложение, которое по каким-то событиям отправляет почту.

Очевидно, что во время отладки/разработки по настоящим живым адресам рассылать ничего не надо.

Как я решил такую проблему с ninject: в зависимости от окружения (dev/stage/prod) у меня инжектятся разные классы для уведомлений: SmtpTransport или FileTransport.

Таким образом единственное место, которое мне пришлось изменить для решения — это код, конфигурирующий контейнер.

Каким будет ваше решение?
Вот кстати ещё две неплохие статьи на эту тематику

wiki.agiledev.ru/doku.php?id=ooad:dependency_injection

wiki.agiledev.ru/doku.php?id=ooad:manage_dependencies_in_php_code

Что-то с хабром у меня сегодня не лады :(
Ага, я знаю, хорошие статьи.

Однако есть существенный недостаток, он же причина, по которой я полез переводить именно эту статью — они сложны. Они академически охватывают типы инъекций, разновидности и т.п. А для использования паттерна надо схватить суть. Почувствовать, что да-дада, вот так работает, вот так круто! А для этого пример должен быть прямолинеен, как вертикаль власти и тупой, как пробка.

Потом можно уже дополнительное почитать.

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

Вот еще одна презентация, которая обладает таким свойством, но опять же на англ.:
Презентация Джеффа Мура на PHP-tek, 2007
>Ссылку на оригинал дать не могу, оригинал внутри дистрибутива :)
Вспомнил как то __autoload вынесли в класс потом хотели его загрузить ))
Если честно, особой пользы для себя не увидел. Хотя не удивлюсь, если просто не сталкивался с подобной необходимостью или просто использовал другой подход.
UFO landed and left these words here
Only those users with full accounts are able to leave comments. Log in, please.