- 1
ORM::factory('comment')->values($_POST,array('folder_id','code','comment','post_id'))->set('post_id',$post_id)->set('user_id',Auth::instance()->get_user()->id)->set('ip',$_SERVER['REMOTE_ADDR'])->create();-
PHP / Говнокод #8628
+165
Запостил:
kyzi007,
23 Ноября 2011
Follow us!
(ц)
Другое дело практическое применение). Ни htx (да там они скорее внутри), ни yampa лично не применял. И haskell-on-horse сд^Wостался без головы.
(Короче не шибко сложнее монад, но профит/сложность ниже).
http://www.haskell.org/arrows/
Это неизлечимо.
$select = $this->_adapter->select()
->from('artists_indexing')
->where('is_indexed=?', ARTIST_STATE_NOT_INDEXED)
->orWhere('is_indexed=?', ARTIST_STATE_FAILED)
->orWhere('is_indexed=?', ARTIST_STATE_PROCESSING)
->limit(1);
Вы конечно можете вызвать все эти методы отдельно и все такое. Но в таком виде это смотриться очень наглядно без мешанины ИМХО
это даже не сахар, а ацетат свинца
для тех, кто в школе ниасилил переменные в трубо паскакале
select abc from sch.tbl where id
Не вижу вообще никаких бенефитов у такой схемы.
Огромный плюс:)
> можно нагадить товарищам
Ну, тогда сам чорт велел.
> Меньше шансов ошибиться.
Три года писал запросы. Ошибки были, из-за любви к копипасте. Но даже в запросах с двумя десятками джойнов всё было вполне очевидно.
> Удобно собирать on-the-fly, опять же.
Как я и писал выше, для рантайм сборки потянет, но тоже не панацея.
> не заморачиваемся с SQL и разницей в диалектах
Если мне не отшибает память, всё равно при смене СУБД придётся переписывать запросы. Плюс, SQL-то всё равно знать нужно.
$realName = new Zend_Form_Element_Text('artist_real_name ');
$realName->setLabel('Реальное имя')
->setValue($data['artist_real_name'])
->setDescription('Если это группа или дуэт не нужно заполнять это поле!')
->addFilter('StripTags')
->addFilter('StringTrim');
Мечтай. Это больше не киллер-фича функциональных языков. Они скоро и до VB дойдут, если ни уже.
http://www.google.kg/search?q=pattern+Fluent+interface&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a
Прочитайте таки эту книжку. Эффорта мало, бенефита много.
> Школота...
no comments.
Не знаю, как вы, а я всё же ощущаю большую идеологическую разницу между fluent interface и, к примеру, AbstractFacotory, Flyweight, Composite, MVC ...
Не даром ведь шаблоны были разбиты на группы:
1. Порождающие
2. Поведенческие
3. Сруктурные
4. Базовые (общего назначения). К которому и относится наш Fluent!
Какую задачу он решает Вы ответил уже сами...
Приведите, пожалуйста, ссылку, где FI причисляют к базовым шаблонам.
2. Вот список наиболее рапространненых патернов (куда входит паттерн о котором мы говорим):
http://ru.wikipedia.org/wiki/%D0%9A%D0%B0%D1%82%D0%B5%D0%B3%D0%BE%D1% 80%D0%B8%D1%8F:%D0%A8%D0%B0%D0%B1%D0%BB% D0%BE%D0%BD%D1%8B_%D0%BF%D1%80%D0%BE%D0% B5%D0%BA%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D 0%B0%D0%BD%D0%B8%D1%8F
3. Мне тяжело вам будет сейчас на скорую руку найти источник откуда я взял что данный
паттерн входит в базовые паттерны общего назначения. Fluent interface из-той же оперы что и эти шаблоны:
Основные
Делегирование
Интерфейс
Неизменяемый объект
т.е отнести их к выше описанным 3 категориям не удасться. Т.е их лучше охарактеризовать как базовые (общие)
Даже если по списку:
Делегирование - позволяет сделать систему гибче, сделать её более прозрачной для клиента.
Интерфейс - повышает гибкость, позволяет компилировать части приложения раздельно, предоставлять множество реализаций, etc.
Неизменяемый объект - позволяет упростить логику многопоточных программ, повысить надёжность системы в целом за счёт уменьшения возможных источников side-effect'ов.
Fluent Interface же никак не влияет на систему в целом. Сам по себе он делает систему более масшабируемой, не снижает потребление ресурсов. Его цель - удобство использования api. Я не говорю, что это ненужная задача (я сам постоянно использую FI на практике). Просто на design pattern не тянет.
selffix
Вам кажется это, что-то более академичным, направлено имено на оптимизацию потребление ресурсов итд.
Для меня же паттерны это - удачные решения тех или инных задач опытными программистами.
Направленными в различные аспекты, как можно догадаться из существующих категоий паттернов.
Некторые из них действительно призваны для эфективной работы с памятью, а некоторые как этот
для удобства заполнения структур итд. Не нужно быть таким категоричным на то они и шаблоны, а не
доктрины
где еще пхпешник может выразить себя рассказав всякой школоте про дезайн потерны
Снизу можете прочитать категию куда отнесли тему
warning: self reference.
В этой категории много статей, косвенно относящихся к design patterns. Там есть, к примеру, "Повторное использование кода".
http://ru.wikipedia.org/wiki/%D0%9A%D0%B0%D1%82%D0%B5%D0%B3%D0%BE%D1% 80%D0%B8%D1%8F:%D0%A8%D0%B0%D0%B1%D0%BB% D0%BE%D0%BD%D1%8B_%D0%BF%D1%80%D0%BE%D0% B5%D0%BA%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D 0%B0%D0%BD%D0%B8%D1%8F
Если ощущаешь, то приведи ещё примеры, которые относятся к к тому же классу, что и fluent interface.
Ты сможешь привести несколько примеров только, если ощущаешь.
В таком случае каждый метод должен возвращать объект, передающийся на вход другому методу: Вот это примерно из той же оперы: проектирование программных интерфейсов.