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

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

ООП в PHP. К сожалению, при использовании ООП падает производительность и повышается расход памяти, поэтому вряд ли есть смысл использовать классы в коде, который выполняется под нагрузкой.
Хороший пример большого открытого проекта на PHP без ООП — Drupal.

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

Неспроста в крупных софтверных компаниях за применение паттернов отвечают лишь архитекторы, люди с самыми высокими скилами в проектировании, остальным же (в том числе и опытным разработчикам, причем особенно им) придумывать те или иные архитектурные конструкции строго запрещают. В результате очень многие программисты хоть и отлично знают паттерны, но сами никогда не принимают решения использовать ли их или нет (хотя и могут иметь свое мнение, жестко критиковать архитекторов... я такие войны застал... ух), это нормально.

Вывод. Знать паттерны проектирования нужно на зубок, и уметь применять. Далее, кроме паттернов проектирования есть еще паттерны других типов, например вычислительные (алгоритмы). Помнить, что для каждой технологии есть свои дополнительные паттерны, их тоже нужно знать. Обязательно знать антипаттерны, чтобы избежать характерных ошибок. А вот потом можно будет работать.

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

Я бы не стал называть это проблемой. Попытки шаблонизировать все подряд вредны, как для проектов, так и для проектировщиков.

Не соглашусь (точнее, согласен только со словами "все подряд", это действительно не нужно).
Создавать проект с нуля с применением паттернов проектирования, или рефакторить проект с целью преобразования беспорядочного кода в более понятную, логичную и стандартизованную структуру, в которой бы было проще разобраться другим разработчикам, весьма полезно (в том числе в этом помогают стандартизованные названия паттернов). Это все равно что Code Conventions в кодинге, только тут — в проектировании.
Другое дело, что нужно это делать прямыми руками, и делать это не за счет написания лишнего мусорного кода (избыточные паттерны-посредники, и т.д.).

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

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

Это вообще, простите, непонятно что... Как может снижаться профессионализм при применении паттернов проектирования?
Скорее всего тут Вы смешиваете паттерны проектирования с высокоуровневым подходом решения тех или иных задач. Тут нет ничего общего, область применения паттернов проектирования — более логичная структуризация кода (одного и того же), не более. В случае паттернов другого типа, например алгоритмов, область применения — портирование паттерна/шаблона в свой проект, и т.д.

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

Цитата (trueW3C):Привести примеры паттернов без ООП
Да, будет интересно.

Думаю уже не актуально.

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

Только профессионализм от этого снижается.

Как может опыт разложенный по местам снижать профессионализм? Ещё раз говорю...паттерн это не нечто новое. Это упорядоченное старое.

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

ООП в PHP. К сожалению, при использовании ООП падает производительность и повышается расход памяти, поэтому вряд ли есть смысл использовать классы в коде, который выполняется под нагрузкой.

В любом языке...процедурное программирование быстрей ООП, но время идёт и процессорное время дешевеет, в отличии от времени программиста.

Самый простой пример в пользу ооп это наследование: Фрилансер наследует все от пользователя интернета, пользователь интернета наследует все от пользователя ПК, тот от человека, человек от животных, ну в конце что-то что зависит от времени.

Если у человека отрастет третья рука, не нужно будет модифицировать класс фрилансеров...они просто это наследуют.

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

Хороший пример использования паттернов - это Зенд Фреймворк

Yii рулит в этом плане...это лучший фреймворк!

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

Половину фрилансеров скоро уже можно будет заменить на кнопку "Сделать сайт".

Уже попытались...Пример тому укоз. И что в итоге? У каждого пятого школьника есть свой крутой сайт, на котором он предлагает стать админом каждому желающему.
Цитата ("r0b1n"):

Пизнес, извините, а не реализация...

Если руки из *опы растут, то про все так можно сказать. Это ваш второй подобный комментарий, если сказать ничего более умного не можете...промолчите.

Кстати стратегия, наблюдатель, шаблон, регистр, одиночка, состояние довольно просто реализуются без ООП.

Хотя Registry скорей антипаттерн...тут порылся его ещё называют Полтергейст
Цитата:

Полтергейст (Poltergeist): Объекты, чьё единственное предназначение — передавать информацию другим объектам

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

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

Только профессионализм от этого снижается.

Как может опыт разложенный по местам снижать профессионализм? Ещё раз говорю...паттерн это не нечто новое. Это упорядоченное старое.

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

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

В любом языке...процедурное программирование быстрей ООП, но время идёт и процессорное время дешевеет, в отличии от времени программиста.

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

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

Хороший пример большого открытого проекта на PHP без ООП — Drupal.

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

Как может опыт разложенный по местам снижать профессионализм? Ещё раз говорю...паттерн это не нечто новое. Это упорядоченное старое.

Элементарно. Да, это упорядоченное старое, только чужое старое и упорядочено чужими руками. Все равно что гонять на бугатти и считать себя великим автомехаником. Не поймите превратно, я за использование паттернов, но своих. Своими ручками разработать шаблоны, которые потом применять для разработки проектов, а не играть в конструктор, собранный по сусекам. Application - это не аппликации.

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

Элементарно. Да, это упорядоченное старое, только чужое старое и упорядочено чужими руками. Все равно что гонять на бугатти и считать себя великим автомехаником. Не поймите превратно, я за использование паттернов, но своих. Своими ручками разработать шаблоны, которые потом применять для разработки проектов, а не играть в конструктор, собранный по сусекам. Application - это не аппликации.

Уверен, что конструкторы используют готовые детали. Паттерны это такие же небольшие детали.

В рамках фриланса придумывать велосипеды даже вредно.

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

Вы сможете объяснить клиенту, что он должен заплатить за медленно работающую систему

Пример...Yii...ни одной глобальной функции, ВСЕ на классах. Но по скорости обгоняет симфони и зен.

Отчего зависит скорость? От программиста! Пример тому ...
Цитата ("werewolf"):

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

Хороший пример большого открытого проекта на PHP без ООП — Drupal

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

Да, я когда-то за каждой милисекундой гнался. Но то время прошло...я пишу с Yii, мне жаль своего времени. Я НЕ ХОЧУ каждый раз копировать постраничную навигацию, авторизацию и прочих будничных хлам...ХОЧУ писать только самое вкусное Да и клиентам дешевле обходится.

ХВАТИТ ЭКОНОЧИТЬ ПРОЦ. ВРЕМЯ! Наше все равно дороже(в разумных приделах)

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

ХВАТИТ ЭКОНОЧИТЬ ПРОЦ. ВРЕМЯ! Наше все равно дороже(в разумных приделах)

Вы просто еще не успели столкнуться с проектами, где производительность действительно важна. Когда количество реквестов превышает 600-700 в секунду, волей-неволей приходится думать над каждой строкой кода, над каждым вызовом функции, над каждой конкатенацией строк и т.д. Именно об этом я и говорю, а не призываю вообще отказаться от ООП и т.д.
И пожалуйста, не нужно писать капслоком, и еще и выделять это жирным. Ваша воинственность мне непонятна.

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

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

Как часто можно услышать в ответ: давайте писать крутые проекты на ассемблере! К чорту ООП, к черту вообще функции...скорость важней.

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

Уверен, что конструкторы используют готовые детали. Паттерны это такие же небольшие детали.

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

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

В рамках фриланса придумывать велосипеды даже вредно.

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

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

Создавать проект с нуля с применением паттернов проектирования, или рефакторить проект с целью преобразования беспорядочного кода в более понятную, логичную и стандартизованную структуру, в которой бы было проще разобраться другим разработчикам, весьма полезно

Если человек не умеет проектировать без ООП, то в ООП ему вообще лучше не соваться.

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

ХВАТИТ ЭКОНОЧИТЬ ПРОЦ. ВРЕМЯ! Наше все равно дороже(в разумных приделах)

Это верно только на сайтах-визитках и никому не нужных порталах. Когда проект действительно хорош, вы никогда не будете стоить дороже нескольких десятков серверов. А точнее, ваш кодинг потребует прикупить еще десяток.

Я не говорю послать проц время далеко и надолго. Я против выражения "ООП это тормоз"

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

А вы впервые слышите, что сейчас также спокойно переводятся критичные участки кода на asm, как и раньше?

Обычно слышу написать участки на C...в такую пропасть пока из знакомых никто не падал...
Мы сейчас говорим об PHP

Так ладно. Забейте на это все.
Я создавал тему, и знал 80% ответов У каждого своё мнение.

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

Конечно на второй способ тратится больше ресурсов, но выгоды тоже больше. Да, это не должно выходить за рамки доступного...но стремится надо все же к последнему.

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

Обычно слышу написать участки на C...в такую пропасть пока из знакомых никто не падал...
Мы сейчас говорим об PHP

В случае с PHP критичный по производительности код обычно портируется на Си, и затем подключается в виде расширения (это в том сулчае, если нет смысла отказываться от PHP).
При этом самый критичный код этих расширений, например ресурсоемкие алгоритмы, могут писаться в том числе и на асме.

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

Я не говорю послать проц время далеко и надолго. Я против выражения "ООП это тормоз"

ООП это не тормоз. Но это не касается PHP... Кроме того, кроме процессорного времени есть еще не менее важный ресурс — используемая память. Чем меньше памяти расходуется, тем больше клиентов одновременно может обработать сервер, даже в случае нереально сверхбыстрого железа. Поэтому это тоже может быть критично, и не в пользу ООП.

ООП человеческое программирование. Для компьютера все человеческое это плохо.

Была когда-то DOS, создали Windows (вначале все гнали мол жрет много ресурсов)
Довольно молодой язык C#, после C++ или пусть даже Pascal, его выучить раз плюнуть. А учится легко потому, что упор на удобство написания кода.
С# работает в 2-5 раза медленней, чем C++ ... но там об утечки памяти можно забыть...встроенный чистильщик.