Насколько релевантный шаблоны разработки OO к веб-разработке в PHP?
Singleton, Декоратор, Краткий обзор, Фабрика, и список продолжают. Насколько релевантный шаблоны разработки OO в разработке приложений PHP для сети? Это делает что-нибудь для производительности? Или это должно только сохранить наклон кода для методов гибкой разработки? Кто крупный благотворитель для реализации этих шаблонов разработки? Действительно ли это - клиент или разработчик?
Я понимаю, что задаю несколько вопросов, но они все касаются той же темы. Я не уверен, что существует необходимость шаблонов разработки OO с языком сценариев, так как она компилируется во время выполнения. Что Вы все думаете? Действительно ли это важно?
5 ответов
Шаблоны проектирования создаются для решения конкретных проблем. Эти проблемы возникают независимо от того, используете ли вы PHP или любой другой язык (хотя шаблоны также могут отличаться в зависимости от языка). Большинство шаблонов уходят корнями в объектно-ориентированный дизайн, но могут быть адаптированы к процедурным параметрам. Используйте шаблон проектирования, если у вас есть проблема, которую он решает, будь то PHP или любой другой язык. Не используйте шаблон проектирования только потому, что это «шаблон проектирования» - знайте, как и когда он применяется, а когда нет.
Сказав это, большая часть того, что делают шаблоны проектирования, - это организация кода для достижения своей цели чистым и понятным способом. Есть и другие способы решения проблемы, но шаблон проектирования - это хорошо известный, ясный и понятный метод. Если вам действительно нужно решить проблему, решаемую конкретным шаблоном, обычно лучше использовать этот шаблон (или адаптировать шаблон), чем выбирать альтернативу.
Таким образом, использование шаблонов там, где это уместно, выгодно как нынешним, так и будущим разработчикам - более чистый и понятный код - и заказчику - меньше времени на изобретение колеса, более надежный и поддерживаемый код. Использование шаблонов, когда они не подходят, никому не приносит пользы; Это потенциально упражнение в разочаровании, пытающееся адаптировать шаблон для решения не связанной проблемы, и, скорее всего, просто усложнит ситуацию.
Каковы алгоритмы (например, быстрая сортировка) для процедурного программирования, шаблоны проектирования - для объектно-ориентированного проектирования. Это проверенный способ решения некоторых распространенных проблем.
Основным выгодоприобретателем является переход, но в качестве побочного эффекта покупатель, вероятно, получит более качественный конечный продукт.
Независимо от того, актуальны они или нет, это зависит от определенных требований к приложению и выбранного вами подхода. Это может показаться лаконичным, но когда вы начнете анализировать свое приложение и сравнивать его требования к дизайну с существующими шаблонами, вы будете знать, как и когда их использовать.
Да, но вы должны выбрать правильные шаблоны для платформы. Безусловно, наиболее важным шаблоном объектно-ориентированного проектирования является MVC (Model-View-Controller), который используют все основные фреймворки (CakePHP, CodeIgniter и т. Д.).
Насколько актуальны паттерны проектирования OO при разработке PHP-приложений для веб?
IMO они очень актуальны для любого нетривиального PHP-приложения, при условии, что используемый вами паттерн применим для конкретной задачи.
Делает ли это что-нибудь для производительности?
Не обязательно, и вы можете воспринимать это как в положительном, так и в отрицательном смысле. Большинство популярных паттернов проектирования напрямую не добавят никаких положительных преимуществ в производительности, а некоторые, накладывающие большее наследование или структуру классов, могут добавить незначительные затраты на производительность (я подчеркиваю - незначительные). Преимущества использования известных паттернов, когда они применимы, перевешивают эти незначительные затраты.
Один пример, который я могу привести, когда паттерн непосредственно улучшает "производительность" (в отношении использования памяти), - это уместное использование паттерна singleton. Если вам действительно нужен только один экземпляр объекта в любой момент времени, то вы минимизируете использование памяти, используя этот экземпляр.
Или это просто для того, чтобы сохранить код компактным для практики гибкой разработки?
Я бы сказал, что правильное использование паттернов делает код более удобным для сопровождения, а не "экономным". Это облегчает любой цикл разработки, включая agile, поскольку код, использующий известные паттерны, легче читать.
Кто является главным бенефициаром внедрения этих паттернов проектирования? Заказчик или разработчик?
В первую очередь разработчик (особенно если речь идет о множественном разработчике (разработчиках), когда команда имеет дело с одним и тем же кодом). Существует косвенное влияние на заказчика, поскольку хорошо написанный код, очевидно, будет иметь меньше ошибок, а программное обеспечение, использующее паттерны, вероятно, будет иметь меньшее время выполнения, связанное с повторным изобретением колеса.
При использовании ООП и не-ООП подходов может быть небольшая разница в производительности , где не-ООП является бит быстрее, но разница будет практически незначительной.
Я думаю, что объектно-ориентированные шаблоны проектирования были бы полезны для организации кода, но вопросы дизайна оставлены на ваше усмотрение. Я думаю, вы выиграете больше, чем пользователь. Пользователь может увидеть один и тот же результат независимо от того, используете ли вы ООП или не ООП.