Имеет ли объектно-ориентированный дизайн место в веб-разработке?
Я работаю в магазине веб-разработки, поэтому, естественно, мы имеем дело с профилями пользователей. Обращаясь к одному из наших сайтов, я заметил, что не было класса "Пользователь", который показался мне странным, так как у нас, конечно же, есть пользователи. Вместо этого сайт полагается на взаимодействие с DataRows (это С#), возвращаемое статическими методами, практически не создавая экземпляр. Я спросил своего босса о создании класса для пользователей, и его ответ заключался в том, что, поскольку объекты должны быть перестроены так часто, его часто не стоит.
Я относительно новичок в веб-разработке, и кажется, что это немного путайте, чтобы создавать объекты каждый раз, когда страница перестраивается, но, с другой стороны, я всегда считал, что объектно-ориентированное программирование полезно. Так что мне любопытно мнение о том, насколько вы, ребята, используете ООП в веб-разработке?
Ответы
Ответ 1
Единственный раз, когда я не использую ООП, когда:
-
Я создаю простой проект для проверки некоторой логики. Это обычно приводит к созданию правильных классов...
-
Я использую Classic ASP (некоторое время, слава богу).
-
Я не программирую.
изменить
3+ года после публикации выше; Я добавляю немного к моему ответу.
ООП отличная и позволяет нам иметь огромную гибкость для того, чтобы несколько систем взаимодействовали с одними и теми же данными/логикой. Тем не менее, есть определенная ситуация, когда вы не захотите загружать множество объектов. А именно, когда вы просто тянете данные для табличного отображения.
Запрос базы данных и получение простой записи, которая сразу же отправляется в браузер, обычно не требует участия ООП. На самом деле вы можете полностью обойти ООП, поскольку табличные данные обычно включают свертывание другой информации (суммы дочерних записей), и вы обычно не хотите извлекать больше данных из базы данных, чем то, что вы фактически используете. то есть. если вы только показываете имя и адрес электронной почты, вы, вероятно, не хотите захватывать имя пользователя, поскольку это просто потраченные впустую циклы.
Теперь, вставляя информацию в БД, обычно приходится следить за тем, чтобы соблюдалась определенная бизнес-логика. Например, имя пользователя следует определенным правилам. В таких ситуациях использование стиля ООП делает вещи более инкапсулированными и легко переносимыми между системами.
Итак, глядя на конкретный пример: я бы не стал беспокоиться о том, чтобы больше не передавать реплику, привязав к репитеру, когда вытащить данные; но у меня был бы класс пользователя, когда я собираюсь создать новый или работать с этим пользователем, чтобы убедиться, что бизнес-правила соблюдены правильно.
Ответ 2
Один вопрос: нужны ли данные для связи с вызовами функции/метода? Если нет, ООП не требуется.
Ваш лучший подход может заключаться в том, чтобы найти пустую доску, создать модель высокого уровня с использованием объектно-ориентированного дизайна, затем с функциональным дизайном, а затем с процедурной. Вы можете удивить себя (и других) результатами. Один и тот же язык может использоваться по-разному в зависимости от проекта. Как упоминалось @wj. ООП - это просто парадигма, не бойтесь выходить за пределы зоны комфорта и дизайна, используя другую парадигму.
Время, затрачиваемое на разработку с использованием разных парадигм, также поможет вам, когда вы подходите к своему начальнику, чтобы обсудить, почему вы должны или не должны использовать текущую парадигму. Большинство боссов оценят, что вы потратили время на исследования, прежде чем подойти к ним с идеей - это не означает, что они согласятся с вашей идеей, но, будучи осведомленным в будущем, потенциально вы получите несколько дополнительных минут его/ее внимания.
ИМХО (не принимайте это лично), "Объектно-ориентированное программирование" упало с подобными "Web 2.0" - своеобразное модное словечко, что является неудачным; вы теперь видите, что разработчики форсируют OOP, где он лучше подходит для использования FP или PP.
Лучшим профессиональным советом, который я могу дать, является проектирование (сначала высокий уровень, затем погружение вниз) в несколько парадигм (сделайте все возможное, чтобы не быть предвзятым - держите открытым) и решите который лучше всего подходит для работы вашего приложения. В моем 15-летнем опыте 75%% времени я считаю ООП ненужным, хотя мой текущий проект строго ООП.
Более важный/актуальный вопрос: "Имеет ли объектно-ориентированный дизайн место в моей текущей веб-разработке?"
Ответ 3
Ваш босс (к сожалению) идиот. OO помогает создавать хорошо структурированный поддерживаемый код. Создание объектов происходит очень быстро, и сборка короткоживущих объектов очень быстро.
У вас здесь преждевременная оптимизация, приводящая к хрупкому коду.
Ответ 4
ООП - не более чем парадигма программирования ! но его важность в том, что hi - это НАСТОЯЩАЯ парадигма в использовании, подразумевающая, что все современные знания и лучшие практики в разработке программного обеспечения будут выражены в соответствии с этим стилем программирования...
Хорошим примером в вашем случае (веб-разработка) является Core J2EE Patterns.
(источник: sun.com)
Ответ 5
Хотя объекты облегчают разработку некоторых программистов, я прочитал прекрасный пример того, как создать весь сайт без ООП. Не один унция. Посмотрите последнюю страницу в 20-страничной серии под названием "Чистый PHP":
http://okmaya.com/clean-php/clean-php-step-20/
Супер легко следовать, чистый способ создания всего веб-сайта. Не путайте ООП, нет супер вложенной папки, нет сумасшедшего кода спагетти, чтобы следить за часами... Просто простые, чистые и хорошо выложенные функции, которые ВСЕ ЕЩЕ, что вам нужно, без использования ООП. И в этом примере есть все, от учетных данных входа/регистрации, раздела администрирования (CMS), даже инструментов для базы данных, чтобы начать работу, функцию поиска, которая использует API-интерфейс mapquest для выполнения почтового индекса/поиска по длине. Я имею в виду, что у него есть ВСЕ для основного проекта или веб-сайта.
Зачем беспокоиться о ООП? Чистый и правильно структурированный процедурный код отлично!
По теме ООП. Я помню еще одну причуду, что все думали, что это круто, и все это сделали, но потом выяснили, что курение дало вам целую кучу проблем.
Придерживайтесь простого, придерживайтесь того, что вы знаете. Будьте экспертом в PHP, и вам больше не придется зависеть от структуры. Не начинайте меня с OOP MVC Framework. Интерпретированные языки для Интернета никогда не должны были быть ООП. ООП просто добавляет еще один уровень сложности. Перестаньте лениться. Используйте свой PHP и узнайте, как программа freakin!
С другой стороны, я вижу, как сделать игры на консоли сложными без ООП. Но опять же, это яблоко апельсинов. Консольные игры сохраняют свои объекты в памяти до выхода игры или уничтожения объекта изнутри игры. Подумайте об этом... Почему у них есть загрузочный бар перед каждым уровнем? Теперь представьте себе веб-страницу, которая должна показывать вам панель загрузки каждый раз, когда она загружается, поскольку она должна создавать объекты из базы данных. SLLOOOOOOWWWWW центральный! И как только вы перейдете от этой страницы, вам нужно начать все заново.
Веб-страницы - это приложения внутри себя. Это как перестройка вашего гонщика-перетаскивателя каждый раз, когда вы идете на стартовую линию, только чтобы разделить его на финише. WTFridge? Шутки в сторону? Эй, супер гениев, которые думают, что ООП - это круто ооочень... Держи свой проклятый ООП на моих сайтах!
Просто говорю, что это из моего 10-летнего опыта работы с веб-разработкой, вы знаете, когда мы использовали код в HTML, один за другим?
Ответ 6
Конечно, да. Вы (и тем более ваш босс) говорите "перестраиваете", как это огромная задача.
Что вы подразумеваете под "перестройкой", это запуск программы. Скажите своему боссу, что ООП вообще глупо, потому что даже в среде рабочего стола каждый раз, когда кто-то запускает часть программного обеспечения, объекты нужно перестраивать, чтобы он даже не стоил того.
Ответ 7
Комментарий Босса бесполезен. Структура .net состоит из объектов и ничего другого. "Ответ" - это объект, даже в "классическом ASP" - почему люди его реализовали, если это было ресурсом неэффективным?