Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 31
Ну в редакторе же есть тэг, code. А за перевод, спасибо!
highlight.hohli.com/ — вот здесь например, поставьте галочку для Хабрахабра и смело вставляйте то, что он сгенерит
спасибо
Эти велосипеды ломают подсветку в кастомных темах, например. А всего навсего надо было использовать тег
P.S. сорри за АП, статью привели как пример поломанной подсветки.
<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 с завершением по типам.
Так что данный паттерн считаю верхом абстракционизма, но уже того абстракционизма, который делается только ради абстракционизма.
Либо автор неудачные примеры привел.
Потому-что в процессе работы люди используют автозавершение по типам.
Именно поэтому в итоге на C# удобнее работать, нежели на нативном PHP.
Это я со временем понял и теперь на PHP все время использую только какой-нить Ecplise с завершением по типам.
Так что данный паттерн считаю верхом абстракционизма, но уже того абстракционизма, который делается только ради абстракционизма.
Либо автор неудачные примеры привел.
Пожалуйста ответьте более развернуто.
Что такое завершение по типам, и как оно решает ту задачу, что описана в этой статье?
Как именно помогает Eclipse справиться с зависимостями между классами?
Что такое завершение по типам, и как оно решает ту задачу, что описана в этой статье?
Как именно помогает Eclipse справиться с зависимостями между классами?
1. Завершение — это когда мы к примеру в сишарпе создаем объект:
Human petya = new Human();
// Потом пишем
petya.
// и нажимаем Ctrl + Space
// IDE выдает нам все методы и свойства класса Human
Аналогично в eclipse и прочих IDE.
2. Eclipse никак не помогает справится с зависимостями.
Я вообще не увидел здесь никакой проблемы.
Пожалуйста проблему почетче опишите.
Human petya = new Human();
// Потом пишем
petya.
// и нажимаем Ctrl + Space
// IDE выдает нам все методы и свойства класса Human
Аналогично в eclipse и прочих IDE.
2. Eclipse никак не помогает справится с зависимостями.
Я вообще не увидел здесь никакой проблемы.
Пожалуйста проблему почетче опишите.
Посмотрите пожалуйста примеры использования во второй части статьи, особенно вот этот:
— Пусть мы хотим написать реализацию Authentication на основе интерфейса фреймворка…
Наш компонент будет использовать общее с фреймворком подключение к БД, и еще мы хотим взять кэширующий компонент третьей стороны.
— на мой взгляд это потенциально трудное место весьма элегантно программируется с помощью этого паттерна.
я, в свою очередь, совсем не понял к чему тут автозавершение, которое дает IDE? Где паттерн мешает работе с методами и интерфейсами?
— Пусть мы хотим написать реализацию 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');
Но это опять же гемор, только сбоку.
Вторую часть читаю.
$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, в которой это всё есть сразу, а не надо корячиться и собирать её.
/**
* @type {MyController}
*/
$controller = $injector->create('MyController');
С кодом не надо корячиться — надо сначала моделировать, а потом его генерить.
Всё.
Зато потом, когда проект начинает быть «пипец» каким большим, то весьма это помогает.
Исптытайте, тык скыть эффект масштаба.
А подсесть на это Вам придется со временем.
Напр., когда выйдет нормальная IDE, в которой это всё есть сразу, а не надо корячиться и собирать её.
>С кодом не надо корячиться — надо сначала моделировать, а потом его генерить.
оно конечно здорово, но код живет и развивается, все заранее не спроектируешь. Если бы так было, как Вы говорите, то рефакторинг нужен бы не был.
оно конечно здорово, но код живет и развивается, все заранее не спроектируешь. Если бы так было, как Вы говорите, то рефакторинг нужен бы не был.
отвечает пользователь Eclipse(plug. PHPE)
@return datatype description
@return datatype description
код все-таки первичен ИМХО.
:) первична задача, которая оплачивается заказчиком.
А код — это всего лишь «один из».
И вообще по мне первичен не код, а его качество.
Это как бэ смещение акцентов:
«Деньги — не главное. Главное их количиство».
Так что работайте в этом направлении ещё усиленней. Либо набирайтесь опыта. Кароче это как бэ дзен. Оно пришло ко мне с неба :)
А код — это всего лишь «один из».
И вообще по мне первичен не код, а его качество.
Это как бэ смещение акцентов:
«Деньги — не главное. Главное их количиство».
Так что работайте в этом направлении ещё усиленней. Либо набирайтесь опыта. Кароче это как бэ дзен. Оно пришло ко мне с неба :)
вторая часть тут:
habrahabr.ru/blogs/php/64078/
habrahabr.ru/blogs/php/64078/
Ничто не мешает сделать сервисный класс, знающий и отдающий нужные типы, а внутри использующий SC, IOC.
Как бэ вернулись к тому же, отчего якобы уходим?
Вообще этот подход уже начинает больше склоняться к аспект-ориентированному подходу, нежели, к объектно-ориентированному.
Причем я всё еще не улавливаю сути его?
Это типа для тех иррационалов, которые сначала делают, а потом думают???
Цель!!! Для каждого движения нужна цель.
Здесь я понимаю цель такая, чтобы вначале делать, а потом думать.
Вообще этот подход уже начинает больше склоняться к аспект-ориентированному подходу, нежели, к объектно-ориентированному.
Причем я всё еще не улавливаю сути его?
Это типа для тех иррационалов, которые сначала делают, а потом думают???
Цель!!! Для каждого движения нужна цель.
Здесь я понимаю цель такая, чтобы вначале делать, а потом думать.
Только сейчас наткнулся на статью, так что откомменчу через 1.5 года только :-)
1. Для .net точно так же есть ninject/castle windsor.
2. Представьте себе задачу: у вас есть приложение, которое по каким-то событиям отправляет почту.
Очевидно, что во время отладки/разработки по настоящим живым адресам рассылать ничего не надо.
Как я решил такую проблему с ninject: в зависимости от окружения (dev/stage/prod) у меня инжектятся разные классы для уведомлений: SmtpTransport или FileTransport.
Таким образом единственное место, которое мне пришлось изменить для решения — это код, конфигурирующий контейнер.
Каким будет ваше решение?
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
Что-то с хабром у меня сегодня не лады :(
wiki.agiledev.ru/doku.php?id=ooad:manage_dependencies_in_php_code
Что-то с хабром у меня сегодня не лады :(
Ага, я знаю, хорошие статьи.
Однако есть существенный недостаток, он же причина, по которой я полез переводить именно эту статью — они сложны. Они академически охватывают типы инъекций, разновидности и т.п. А для использования паттерна надо схватить суть. Почувствовать, что да-дада, вот так работает, вот так круто! А для этого пример должен быть прямолинеен, как вертикаль власти и тупой, как пробка.
Потом можно уже дополнительное почитать.
Вот это я тут как раз и увидел. Возможно малость язык у меня тяжеловат, но я старался: по-английски многим лень чиатать, да и саму статью еще вытащить надо из архива.
Вот еще одна презентация, которая обладает таким свойством, но опять же на англ.:
Презентация Джеффа Мура на PHP-tek, 2007
Однако есть существенный недостаток, он же причина, по которой я полез переводить именно эту статью — они сложны. Они академически охватывают типы инъекций, разновидности и т.п. А для использования паттерна надо схватить суть. Почувствовать, что да-дада, вот так работает, вот так круто! А для этого пример должен быть прямолинеен, как вертикаль власти и тупой, как пробка.
Потом можно уже дополнительное почитать.
Вот это я тут как раз и увидел. Возможно малость язык у меня тяжеловат, но я старался: по-английски многим лень чиатать, да и саму статью еще вытащить надо из архива.
Вот еще одна презентация, которая обладает таким свойством, но опять же на англ.:
Презентация Джеффа Мура на PHP-tek, 2007
>Ссылку на оригинал дать не могу, оригинал внутри дистрибутива :)
Вспомнил как то __autoload вынесли в класс потом хотели его загрузить ))
Вспомнил как то __autoload вынесли в класс потом хотели его загрузить ))
Если честно, особой пользы для себя не увидел. Хотя не удивлюсь, если просто не сталкивался с подобной необходимостью или просто использовал другой подход.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Phemto и Паттерн Dependency Injection. Часть 1