Паттерны программирования и PHP

Цитата ("trueW3C"):

Я создавал тему, и знал 80% ответов

Паретто сказал бы, что верными являются 20%, которых вы не знали.

Цитата ("trueW3C"):

сделать, чтобы потом неоднократно использовать.

Именно сделать, а не действовать по принципу "загуглил, заюзал, запостил". Вроде римляне по-другому эту фразу переводили.

Я вижу топик так:
trueW3C говорит, что надо паттерны пихать во все щели.
tvv добавляет, что изредка надо обращать внимание на нецелесообразность их использования.
Lisio говорит, что не изредка, а почти всегда, и не чужие использовать, а свои.

Цитата ("trueW3C"):

Довольно молодой язык C#, после C++ или пусть даже Pascal, его выучить раз плюнуть.

Еще бы, Hello World через пару минут пишется. Из них 2 минуты грузится IDE =)

Цитата ("Lisio"):

"загуглил, заюзал, запостил"

Я с ооп давно знаком.

Цитата ("Lisio"):

trueW3C говорит, что надо паттерны пихать во все щели.

А началось с вопроса "кто знает, кто использует"

Цитата ("Lisio"):

Еще бы, Hello World через пару минут пишется. Из них 2 минуты грузится IDE =)

Пишется...офигенно пишется... с антипаттерном "Магическая кнопка".

        private void button1_Click(object sender, EventArgs e)

        {

            MessageBox.Show("Hello!");

        }

У меня IDE 5 сек грузится.

Цитата ("trueW3C"):

Я с ооп давно знаком.

Я про поиск паттернов в сети, вместо создания своих.

Цитата ("trueW3C"):

У меня IDE 5 сек грузится.

Без инсталляции? =)

Цитата ("Lisio"):

Я про поиск паттернов в сети, вместо создания своих.

Свои паттерны...звучит страшно.

Ничего страшного, обычная генетика. Берется ваш паттерн, навешивается слегка модифицированный конфиг и получается новый класс. Потом он идет в 1й класс, а через 10-15 лет процесс повторяется. Разница в том, что создав его сами, вы можете его воспитывать. А взяв чужой - только улучшать демографию.

Цитата ("Lisio"):

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

Цитата ("Lisio"):

Поэтому берут чужие, как правило, трехколесные. А сзади еще кузовок с лишними функциями.

Обычно для того чтобы включить профайлинг ставится какой-то ключ, например debug, поэтому считаю, что редактировать классы, вырезая ненужный код в большинстве случаев это экономия на спичках.
Premature optimization is the root of all evil © Кнут.

Для тех, кто в танке: веб-программирование несколько отличается от настольного программирования в самой своей основе. А именно, в настольных программах мы при загрузке программы по сути грузим все необходимое ядро сразу, а потом спокойно себе работаем, программа шуршит, и все такое... А при работе с сайтом КАЖДАЯ загрузка страницы - это по сути своей загрузка программы заново!
Я, конечно, понимаю, что многие (и я не исключение) пришли в веб-программирование после долгого периода работы с настольными программами, но все-таки, профессионалы мы или где? ООП вещь замечательная, особенно для проектирования систем, но при реализации конкретного кода в веб-программировании классы нужны как собаке пятая нога. Как и прочие громоздкие вещи, притянутые с собой из настольного программирования.

И ладно бы это просто была загрузка программы, так каждый ваш паттерн еще грузит несколько сотен своих мелких файлов.

Цитата ("Lisio"):

И ладно бы это просто была загрузка программы, так каждый ваш паттерн еще грузит несколько сотен своих мелких файлов.

Хватит писать бред о паттернах, какие сотни файлов грузит "Одиночка", "Фабрика", "Стратегия", "Адаптер" и т.д.?

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

Filipchuk +1.
При нынешней стоимости вычислительных мощностей экономить на них в пользу сложного в поддержке кода не рационально. Мне не приятно осознавать, что сейчас выгоднее говняный код, на мощном железе, чем нормальный код на обычном. Это уж не говоря о том, что простой в поддержке код может быть медленее. И часто упор делается не на производительность, которая важна, кстати, не всегда, а на дешевизну и время разработки. Всегда предупреждаю заказчика, если решение паршивое, а нормальное решение будет воот такое, а стоить будет вот столько - обычно мало интересует этот вопрос. Главное что бы быстро и не дорого, а дедик все прожует.
Паттерны применяю. Применять, правда, начал до того, как узнал о них

Цитата ("frig"):

Паттерны применяю. Применять, правда, начал до того, как узнал о них

аналогично, так сказать, на подсознательном уровне

Цитата ("filipchuk"):

так сказать, на подсознательном уровне

до правильных вещей многие люди доходят независимо друг от друга. а еще "все украдено до нас"

Так и будете спорить, что важнее - скорость загрузки или чистота кода и удобство программиста, до тех пор пока не выйдете за рамки "или-или"...
Ну на здоровье, спорьте дальше...

Покажите хоть один ВАШ проект, где использвание ООП критично. Или просто готовить не умеем, поэтому и невкусно?

Raznomir, реально же все относительно. скорость загрузки - относительна. Стремиться к максимальной скорости загрузки - нужно, но если в этом есть смысл. Просто так оптимизация рази оптимизации - зло. Верно?
Также как и удобство тоже относительно. Тулить решения туда, где они не уместны - зло и удобным это не будет. Да и касательно поддержки и развития тоже есть нюансы.
Каждому решению свое место. Крайности они нужны и важны тогда, когда это значимо. Если ООП это удобно и не влияет фатально на производительность, то почему бы этим не пользоваться? Только из идеологических соображений?

На 100% согласен с тем, что крайности не нужны нигде, и чисто из идеологических соображений отказываться от ООП не нужно.
Но меня удивляют именно споры в стиле "если использовать ООП, то все будет грузиться медленно! а если не использовать, то будет все быстро, но неудобно для программиста и грязный код!". Повторяю, выйдите за рамки "или-или", и найдите вариант, где получается и быстро, и удобно. Лично я нашел. Но не скажу.
Сами думайте, программисты вы или где?
Маленькая подсказочка только: в настольном программировании есть огромная куча ограничений, которых нет в веб-программировании, но которые все так же сидят в мозгах у программистов и не дают адекватно мыслить. Сбросьте эти ограничения, и увидите, насколько легче станет жить (программировать).

Цитата:

Но меня удивляют именно споры в стиле "если использовать ООП, то все будет грузиться медленно! а если не использовать, то будет все быстро, но неудобно для программиста и грязный код!".

А разве было такое? Я видимо не так понял.

Цитата:

Лично я нашел. Но не скажу.

Не жадничайте, поделитесь. Ну пожаааалуйста.

Разномир, полностью согласен, что нет зависимости между "ООП/медленно" и "Процедуры/быстро", все зависит от реализации программистом

Цитата ("frig"):

А разве было такое? Я видимо не так понял.

А перечитайте посты выше. Разве не похоже? Одни спорят, что хлеб лучше чем молоко, а другие, что молоко лучше чем хлеб... Прям дети в песочнице...
Цитата ("frig"):

Не жадничайте, поделитесь. Ну пожаааалуйста.

Ну еще одна подсказочка, из более очевидных.
Вот есть следующая задача (реальная задача, кстати, которую можно решить по-разному):
Есть два объекта (Методы доставки и Регионы доставки), которые могут создаваться/удаляться в процессе работы сайта как угодно, сами экземпляры объектов храняться в обычных таблицах в БД, тут все просто, стандартно и очевидно.
И есть значение Стоимость, которое существует на связи этих двух объектов, то есть для каждого региона и метода доставки будет своя одна конкретная стоимость.
Как бы вы решили эту задачу с точки зрения хранения данных?
Цитата ("frig"):

Я, кстати, настольным почти и не занимался, так что меня из той области ничего не парит.

Как ни странно, но это даже в чем-то "плюс"