Имеет ли объектно-ориентированный дизайн место в веб-разработке?

Я работаю в магазине веб-разработки, поэтому, естественно, мы имеем дело с профилями пользователей. Обращаясь к одному из наших сайтов, я заметил, что не было класса "Пользователь", который показался мне странным, так как у нас, конечно же, есть пользователи. Вместо этого сайт полагается на взаимодействие с 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" - почему люди его реализовали, если это было ресурсом неэффективным?