- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
function decode_php_abbr($abbr){
if(strpos($abbr,'PHP')!==false){
$abbr=str_replace('PHP','PHP: Hypertext Preprocessor',$abbr);
decode_php_abbr($abbr);
}
else echo $abbr;
}
decode_php_abbr('PHP');-
PHP / Говнокод #17435
+159
Расшифровываем аббревиатуру PHP или когда на работе немного скучно.
Запостил:
VokaMut,
13 Января 2015
Follow us!
Что бы вывелась всё таки когда расшифруется)
> Ну там декоратор
http://framework.zend.com/manual/1.12/ru/zend.form.standardDecorators.html
> или фабрику
http://framework.zend.com/manual/1.12/ru/zend.db.adapter.html
http://framework.zend.com/manual/1.12/ru/zend.uri.chapter.html
http://framework.zend.com/manual/1.12/ru/zend.paginator.usage.html
http://framework.zend.com/manual/1.12/ru/zend.navigation.pages.html
Ну понятно, что это, как бы, придаёт плавное скольжение следующим использователям кода... то, сё. Но ведь это такой дирижабль получается. С бассейнами, полями для гольфа и с футбольной командой. Как же они взлетают со всей этой хернёй?
Есть "абстрактная фабрика", а есть "фабричный метод" и это две большие разницы.
Ой, ну прям большая-большая разница... В одном случае - один метод и, соответственно, один тип создаваемых продуктов, в другом - несколько. В чём там еще отличия то?
Фабричный метод скрывает от нас процесс конструирования объекта выбирая конкретный класс и, возможно, заполняя его нужными параметрами если это нельзя сделать в конструкторе (например нельзя в конструкторе зарегистрировать свежесозданный объект, ибо утекание ссылки будет, а в методе фабричном -- можно)
Абстрактная фабрика же дает нам стратегию создания целого семейства объектов отвязывая нас от конкретной имплементации (хрестоматийный вариант это WidgetFactory со всякими createButton которые вернут KDEButton, GnomeButton итд).
Ну а по большому-то счету все паттерны про одно и тоже)
-----
Боже, какой я ООПдрочер:-/
+++++++++++
в пхп паттерны ненужны. на говнокодят макаки и ладно.
Он сказал что в больших проектах он нужен, а в маленьких, пожалуй нет.
- И правда... нахуй он нужен то?
- Вы приняты!
В любом проекте есть библиотечные функции/методы, которые наследовать бессмысленно и глупо. Конечно, если не аопнутый во всю голову.
Препроцессор - это одна из самых больших крестопроблем. Именно благодаря ему крестопроекты собираются по полчаса (либо требуют идиотские костыли типа precompiled headers) и могут случайно нарушить ODR. По сравнению с ним синглтоны - безобидные пушистые мышки.
Наследование нинужно. Да и никакого наследования не существует. Это всего лишь... удобный сахарок для агрегации и форвардинга.
> Yuyushki
а я уж подумал борманд матом ругается и вообще охренел. А в итоге оказалось мои мысли выдают мою испорченность
Ты хоть представляешь, что теперь миллионы поливаноблядей готовы сделать с твоим грешным телом?
сх?
ゆゆ式 Перевод у гуглотранслейта суровый...
> Он сказал что в больших проектах он нужен, а в маленьких, пожалуй нет.
а вдруг он ретроград, не расслышал и подумал "зачем нужен Monotone?"
Он сказал, что синглтон не нужен, потому что в ПХП и без этого есть @include_once
- ПХПшника спросили на собеседовании зачем нужен синглтон...
(30 тиков на ответ)
(30 тиков на ответ)
- Получать ролтон за каждую строчку кода
- Тугодум!
Похвально. Сразу видно, что Царь, а не заедушный питушок.
роллтон
http://gadgetsin.com/uploads/2010/11/ramen_noodle_cup_usb_humidifier.jpg
Я сейча уже на три раза перечитывал эти определения и на русском и на английском, и так и не понял, почему фабричный метод не является всего лишь частным случаем абстрактной фабрики...
Для аналогии: можно-ли назвать булеву переменную конечным автоматом?
Фабричный метод: клиент хочет запилить некую хуёвину, имеющую известный ему интерфейс. Если у него есть какие-то требования к этой хуёвине - их совсем мало, и они передаются прямо в метод. Конкретный класс этой хуёвины и большую часть её настроек определяет фабричный метод.
Абстрактная фабрика: клиент хочет запилить несколько взаимосвязанных хуёвин, имеющих известные ему интерфейсы. Если у него есть какие-то требования к этой хуёвине - их немного, и они передаются прямо фабрике. Конкретные классы этих хуёвин и большую часть их настроек определяет абстрактная фабрика.
Строитель: клиент хочет запилить некую хуёвину, имеющую известный ему интерфейс. При этом он, сука, привередливая, и у него куча требований к ней: "чтоб сиськи третьего размера, готовить умела и мозг не ебала!". Конкретный класс этой хуёвины и какую-то часть её настроек определяет строитель.
Там, имхо, настолько тонкие границы между юзкейсами этих трёх паттернов, что их почти не видно... И разве гибрид фабрики и билдера не имеет права на жизнь? В общем-то можно было описать все эти 3 случая одним паттерном и не париться...
* каждый раз одно и тоже (синглтон)
* по инстансу на запрос (храница в реквесте)
* каждый раз новый
* результат работы хитрого фабричного метода
* по одному на поток (практически тозе самое что и с реквестом)
* по одному на приложение
* ваш вариант
* ничего из выше перечисленного
офигенно же!
Возможно, вы имели в виду это две большие задницы