Почему я не вижу реального смысла для использования ООП?

Возможный дубликат:
Классы. В чем смысл?

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

Я имею в виду, я думаю, что получил теорию. Это парадигма, другой способ думать и решать проблему. Я знаю все точки коммутации: повторное использование кода, инкапсуляция, улучшенная обработка ошибок, упрощение обслуживания, наследование, дизайн по контракту, улучшенная документация, агрегация, состав, некоторые шаблоны проектирования...

Тем не менее, отпустите реальную сделку. Скажем, у меня есть следующее:

  • базу данных и класс для доступа и запроса.
  • У меня есть таблица с именем person и другая таблица с именем address
  • Простой бизнес-правило: у одного человека может быть один или несколько адресов (дома, работы, доставки...), простого отношения к многим.
  • У меня есть класс высокого уровня для операций commom (CRUD). Каждая таблица имеет класс, который является расширением от этого.
  • Конечно, каждый класс (человек и адрес) имеет свои собственные методы: например, getAddressByLocation или getPersonsByAge.
  • Также есть дюжина просмотров и пара форм

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

Листинг 50 человек означает создание 50 экземпляров, таких как crud, фильтрация загрузок, проверка правильности и т.д., когда мне нужно запустить запрос и просто вывести результаты с помощью простого цикла.

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

Я думаю, это случай для создания новых классов или простых скриптов, чтобы просто обрабатывать выходы и отчеты? Если да, значит, это означает двойное усилие, использование ООП бессмысленно, как только мне понадобится создать много разных классов для одного и того же объекта базы данных. Кодирование становится сложнее, обслуживание не охлаждает.

Я что-то упустил? Или это недостаток подхода ООП?

Должны ли мы пожертвовать прямой точкой, тонким, более быстрым кодом, чтобы ускорить разработку и обслуживание?

ИЗМЕНИТЬ

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

Во-первых, я приправлен к действительно действительно крупным проектам (я работал в IBM по продаже для Sprint/Nextel USA и Directv North America, поэтому я привык видеть, что каждый терабайт обрабатывается ежедневно).

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

ОТВЕТЫ

Ответ 1

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

OOP основан на принципе, что разработчики стоят дорого, а оборудование дешево. Он использует этот принцип, чтобы вести к высокоподдерживаемому (легко исправить в долгосрочной перспективе) и высоко адаптируемому коду (легко изменить в долгосрочной перспективе). И если вы покупаете 60/60 Rule (в котором говорится, что 60% времени разработки находится в обслуживании, а 60% того времени - из-за улучшений), то ремонтопригодность является конечной целью профессионального программирования.

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

О, и, вопреки распространенному мнению, ООП не собирается никогда ничего не кодировать дважды. Это DRY (Не повторяйте себя). Хотя он часто используется с ООП, он не привязан напрямую. На самом деле, я бы посоветовал при разработке, что вы не следуете DRY, как правило. Стреляйте в нее как цель, но пусть это будет руководство больше, чем правило. Как сказал Фред Брукс, планируйте выбросить его; вы будете, во всяком случае. (Из The Mythical Man-Month). Если вы строго никогда не повторяете себя, вы завершите повторное выполнение много работы, когда придет время бросить что-то, что вы не получили в первый раз. Только когда он будет построен и работает хорошо, вы должны начать его снижать и действительно сделать код DRY. (личное мнение как минимум)...

Ответ 2

Это, как вы сказали, парадигма. У этого есть сильные и слабые стороны, как любая другая парадигма. Где я думаю, вы ошибаетесь, это понятие материально значимого. Что делает 50 экземпляров большим числом? Возможно, вам трудно отслеживать 50 сдержанных вещей (вероятно, для всех людей), но это не значит, что это сложно для компьютера. Это 50 не так просто, потому что это кажется вам большим. Это, безусловно, большой по сравнению с вашим примером простой script для извлечения данных и сопоставления результатов, но компромиссы должны быть очевидными, вы указали большинство из них, когда указали на сильные стороны ООП. Более интересный момент для рассмотрения - когда эти сильные стороны перевешивают слабые стороны. Гораздо больше идет на этот вызов, чем то, что вы здесь определили, включая размер кодовой базы, количество вовлеченных разработчиков, их относительное умение друг к другу, как долго код останется в производстве и многое другое.

Ответ 3

Чтобы предоставить вам простой пример о том, что кажется вашей главной заботой:

$list = DB::query($query);

foreach ($list as $person)
{
  // $person->name
  // $person->address
  // .. and so on 
}

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

Ответ 4

Я боюсь, что то, что вам не хватает, - это настоящий опыт долгое время работы с большим проектом. Это означает, что у вас есть 100% теоретические концепции, но они теоретические. Когда я впервые изучил функцию программирования (в C), я задавался вопросом, зачем нам это нужно. Но потом, когда я начал кодировать нечто большее, чем раньше, я понял, зачем они нужны. То же самое происходит, когда я впервые узнал ООП. Зачем нам это нужно? Но теперь я не могу много думать без него. Итак, мое лето, попытайтесь внести свой вклад в какой-то настоящий большой проект. По крайней мере, в разработке программного обеспечения недостаточно теории.

И если у вас уже есть достаточно крупных проектов, пожалуйста, проигнорируйте этот ответ.

Ответ 5

Если вы посмотрите на DDD, у вас есть независимый слой домена, который содержит объекты домена; каждый из которых содержит свойства и логику домена. Другим уровнем является инфраструктура, в которой хранятся репозитории (где ваши операции CRUD реализованы в соответствии с конкретным ресурсом и технологией).

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

Считаете ли вы, что получение 50 элементов со сложной логикой домена приведет к урон вашей системе?

Ответ 6

Ваши запутанные рамки с парадигмой.

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

Это упрощенный подход, и, как вы нашли, может привести к экспоненциальному росту числа запросов.

Лучше всего создать класс factory, который возвращает массивы лиц со всеми их адресами. Этот объект factory объединяет ваш запрос и запускает как можно меньше запросов, прежде чем создавать объекты, передавая строку из базы данных (или DTO) в каждый новый экземпляр Person.

Помните, что не все объекты являются прямым аналогом реального мира. Люди не производятся на фабриках, но на самом деле у вас нет людей, не так ли?

Factory + Репрезентативный объект + (необязательно) Объект передачи данных является ROBUST и проверенным и проверенным компонентом фрейма в большинстве широкомасштабных приложений, объектно ориентированных.

Но не все. Есть и другие способы обмануть этого кота.

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

Помните. ООП почти никогда ничего не кодирует. Рамки - это выборочное решение о том, что делать дважды, в интересах упрощения обновления, обновления и поддержки кода.

Ответ 7

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

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

Ответ 8

Ты застрял из-за "OOP = парадигмы". В действительности и в отношении PHP это всего лишь нотационный стиль. Когда у вас есть гибридный язык, вы должны использовать лучший подход для каждой части приложения. И разница между процедурами и объектами - это просто внешний вид API.

Да, есть группировка и наследование, и вы можете абстрагироваться и обобщать код полезности лучше с объектными структурами. Но для фактического поведения и функциональности вы не должны ограничивать себя ни методологией. Не каждый гвоздь объектно-ориентированный, и не каждый винт является процедурным. Все о украшении API.

Кроме того, забудьте о различиях в микропроцессоре.

Ответ 9

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

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

Ответ 10

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

FYI ваши общие точки, многие из них разделяются в других парадигмах.

Ответ 11

Не забудьте проверить!

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

Это особенно актуально, если вы используете такие языки, как .Net, с такой структурой, как MVP, потому что, отделяя объекты, вы действительно прибиваете слои и быстрорастущие горизонты кода.