Имеет ли процессуальное программирование какие-либо преимущества перед ООП?

[Edit:] Раньше я задавал этот вопрос, возможно, плохо сформулировал вопрос о том, когда использовать ООП и когда использовать процедурное программирование - некоторые ответы подразумевали, что я просил помочь понять ООП. Напротив, я много использовал ООП, но хочу знать, когда использовать процедурный подход. Судя по ответам, я полагаю, что существует довольно сильный консенсус в отношении того, что ООП обычно является лучшим всесторонним подходом, но следует использовать процедурный язык, если архитектура ООП не будет предоставлять какие-либо преимущества повторного использования в долгосрочной перспективе.

Однако мой опыт работы с Java-программистом был иным. Я увидел массивную программу Java, которую я создал, переписанную Perl-гуру в 1/10 кода, который я написал, и, по-видимому, столь же прочен, как и моя модель совершенства ООП. Моя архитектура увидела значительное количество повторного использования, и все же более сжатый процедурный подход дал превосходное решение.

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

Может ли кто-нибудь предложить примеры того, как выглядят эти сценарии?

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

Ответ 1

Я бы предложил использовать наиболее сжатый, основанный на стандартах подход, который вы можете найти для любой заданной проблемы. Ваш коллега, который использовал Perl, продемонстрировал, что хороший разработчик, который хорошо знает конкретный инструмент, может добиться отличных результатов независимо от методологии. Вместо того, чтобы сравнивать ваши проекты Java-pers-Perl в качестве хорошего примера дебатов по процедурному и противному ООП, я хотел бы видеть грань между Perl и аналогичным языком, таким как Ruby, который также имеет преимущества объектной ориентации. Теперь что-то я хотел бы увидеть. Я предполагаю, что Ruby выйдет на первое место, но я не заинтересован в том, чтобы спровоцировать здесь языческую пламенную войну - я считаю, что вы выбираете подходящий инструмент для работы - любой подход может выполнить задачу в наиболее эффективном и надежном возможно. Java может быть надежной из-за своей объектной ориентации, но поскольку вы и ваш коллега и многие другие, которые переходят на динамические языки, такие как Ruby и Python, находят эти дни, есть гораздо более эффективные решения, будь то процедурные или ООП.

Ответ 2

Мне нравятся правила Glass 3, когда дело доходит до повторного использования (что, кажется, то, что вас интересует).

1) Сборка многоразовых компонентов в 3 раза сложнее, чем одноразовых
2) Многократно используемый компонент должен быть опробован в трех различных приложениях, прежде чем он станет достаточно общим, чтобы принять его в библиотеку повторного использования.

Из этого я думаю, что вы можете экстраполировать эти следствия

а) Если у вас нет бюджета в 3 раза больше времени, которое понадобится вам для создания одноразового компонента, возможно, вам следует отложить повторное использование. (Предполагая сложность = время)
б) Если у вас нет 3 мест, где вы будете использовать компонент, который вы создаете, возможно, вам стоит остановиться на создании компонента, который можно использовать повторно.

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

Ответ 3

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

С моей точки зрения, самым большим преимуществом ООП является организация кода. Это включает в себя принципы СУШКИ и инкапсуляции.

Ответ 4

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

Ответ 5

Те, кто неукоснительно поддерживают ООП, не имеют никаких фактов, оправдывающих их поддержку, как мы видим и в этих комментариях. Они обучены (или промыты мозги) в университетах, чтобы использовать и хвалить только ООП и ООП, и поэтому они поддерживают это так слепо. Они вообще что-то сделали в PP? Кроме защиты кода от неосторожных программистов в командной среде, ООП предлагает мало. Лично работая в PP и OOP в течение многих лет, я считаю, что PP прост, понятен и более эффективен, и я согласен со следующими мудрыми мужчинами и женщинами:

(Ссылка: http://en.wikipedia.org/wiki/Object-oriented_programming):

Ряд известных исследователей и программистов критиковали ООП. Вот неполный список:

Лука Карделли написал статью под названием " Плохие инженерные свойства объектно-ориентированных языков ".
Ричард Столлман писал в 1995 году: "Добавление ООП в Emacs явно не является улучшением; я использовал ООП при работе с оконными системами Lisp Machine, и я не согласен с обычным мнением, что это превосходный способ программирования".
Исследование Potok et al. не показал существенной разницы в производительности между ООП и процедурным подходом.
Кристофер Дж. Дэйт заявил, что критическое сравнение ООП с другими технологиями, в частности реляционными, затруднено из-за отсутствия согласованного и строгого определения ООП. Предлагается теоретическая основа ООП, которая использует ООП в качестве своего рода настраиваемой системы типов для поддержки СУБД.
Александр Степанов предположил, что ООП предоставляет математически ограниченную точку зрения, и назвал ее "почти таким же обманом, как искусственный интеллект" (возможно, ссылаясь на проекты и маркетинг искусственного интеллекта 1980-х годов, которые иногда рассматриваются как чрезмерно усердные в ретроспективе).
Пол Грэм предположил, что цель ООП состоит в том, чтобы выступать в качестве "механизма скотоводства", который удерживает посредственных программистов в посредственных организациях от "слишком большого ущерба". Это за счет замедления продуктивных программистов, которые знают, как использовать более мощные и более компактные методы.
Джо Армстронг, главный изобретатель Erlang, говорит: "Проблема с объектно-ориентированными языками заключается в том, что у них есть вся эта неявная среда, которую они носят с собой. Вы хотели банан, но вы получили гориллу, держащую банан и целые джунгли ".
Ричард Мэнсфилд, автор и бывший редактор COMPUTE! Журнал утверждает, что "как и многие другие интеллектуальные причуда за эти годы (" актуальность ", коммунизм," модернизм "и т.д. история усеяна ими), ООП будет с нами до тех пор, пока в конце концов реальность не утвердится. в настоящее время пронизывающий как университеты, так и рабочие места, ООП вполне может оказаться долговременным заблуждением. Целые поколения идеологизированных программистов продолжают выходить из академии, приверженные ООП и ничего, кроме ООП, до конца своей жизни ". а также говорится, что "ООП - это написание программы, а обеспечение безопасности в аэропорту - это полет".

Ответ 6

Я думаю, что принцип DRY (Do not Repeat Yourself) в сочетании с небольшим Agile - хороший подход. Постройте свою программу постепенно, начиная с простейшей вещи, которая работает, затем добавляет функции по одному и повторно заставляет ваш код по мере необходимости идти вперед.

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

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

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

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

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

Ответ 7

Если проект настолько мал, что он будет содержаться в одном классе и не будет использоваться очень долго, я бы рассмотрел возможность использования функций. Альтернативно, если язык, который вы используете, не поддерживает OO (например, c).

Ответ 8

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

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

Вы можете использовать очень эффективные алгоритмы, но это будет недостаточно быстро, пока вы не оптимизируете использование кеша. Это может привести к увеличению производительности ваших данных. Это означает, что CPU не нуждается в извлечении байтов из ОЗУ, он их знает. Чтобы достичь этого, вы должны попытаться хранить свои данные близко друг к другу, размер исполняемого файла и данных должен быть минимальным, и попробуйте использовать как можно меньше указателей (используйте статические глобальные массивы фиксированного размера, где вы можете себе позволить).

Если вы используете указатели, вы постоянно прыгаете в памяти, и ваш процессор должен перезагружать кеш каждый раз. OOP-код полон указателей: каждый объект хранится по его адресу памяти. Вы вызываете new всюду, которые распространяют ваши объекты по всей памяти, что делает оптимизацию кеша практически невозможной (если у вас нет распределителя или сборщика мусора, который держит вещи близко друг к другу). Вы вызываете обратные вызовы и виртуальные функции. Компилятор обычно не может встроить виртуальные функции, а вызов виртуальной функции относительно медленный (перейти к VMT, получить адрес виртуальной функции, вызвать его [это включает в себя толкание параметров и локальных переменных в стеке, выполнение функции затем всплывает все]). Это очень важно, когда у вас есть цикл от 0 до 1000000 25 раз в секунду. Используя процедурный стиль, нет виртуальной функции, и оптимизатор может встроить все в эти горячие контуры.

Ответ 9

Оба понятия не являются взаимоисключающими, очень вероятно, что вы будете использовать PP вместе с OOP, я не вижу, как их отделить.

Ответ 10

Я думаю, что пригодность ООП больше зависит от области, в которой вы работаете, чем от размера проекта. Есть некоторые предметные области (САПР, имитационное моделирование и т.д.), Где ООП естественно относится к концепциям. Тем не менее, существует много других областей, где отображение заканчивается неуклюжим и несоответствующим. Многие люди, использующие ООП для всего, тратят много времени, пытаясь искривить квадратные колышки в круглые отверстия.

OOP имеет место, но так же, как и процедурное программирование, функциональное программирование и т.д. Посмотрите на проблему, которую вы пытаетесь решить, затем выберите парадигму программирования, которая позволяет вам написать простейшую возможную программу для ее решения.

Ответ 11

Одна из целей ООП заключалась в том, чтобы сделать повторное использование проще, но это не единственная цель. Ключом к эффективному использованию объектов является дизайн шаблонов.

Мы все привыкли к идее алгоритмов, которые рассказывают нам, как объединить разные процедуры и структуры данных для выполнения общих задач. Наоборот, взгляните на Design Patterns от Gang of Four за идеи о том, как объединить объекты для выполнения общих задач.

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

Помните, что реализация интерфейсов столь же важна, если не важнее наследования. Еще в тот момент, когда С++ стал примером объектно-ориентированного программирования, а использование интерфейсов скрыто по сравнению с наследованием (виртуальные функции и т.д.). С++ Legacy означало, что больше внимания уделялось повторному использованию поведения в различных учебниках и широких обзорах. С тех пор Java, С# и другие языки переместили интерфейс до большего фокуса.

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

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

Ответ 12

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

Одна из моих эвристик основана на том, как "состояние" ситуации. Если процедура загрязняет пространство имен или может повлиять на глобальное состояние (в плохом или непредсказуемом виде), то инкапсуляция этой функции в объект или класс, вероятно, будет разумной.

Ответ 13

Процедурные программы могут быть проще для определенного типа программы. Как правило, это короткие script -подобные программы.

Ответ 14

Рассмотрим этот сценарий: Ваш код не OO. У вас есть структуры данных и многие функции во всей вашей прогаме, которые работают с структурами данных. Каждая функция принимает структуру данных как параметр и выполняет разные действия в зависимости от поля "data_type" в структуре данных.

ЕСЛИ все работает и не будет изменено, кому это нужно, если это OO или нет? Это работает. Это было сделано. Если вы можете добраться до этой точки быстрее, написав процедурно, то, возможно, это путь.

Но вы уверены, что это не изменится? Скажем, вы, вероятно, добавите новые типы структур данных. Каждый раз, когда вы добавляете новый тип структуры данных, в котором должны работать эти функции, вы должны убедиться, что находите и модифицируете каждую из этих функций, чтобы добавить новый случай "else if", чтобы проверить и добавить поведение, которое вы хотите чтобы повлиять на новый тип структуры данных. Боль этого возрастает по мере того, как программа становится все сложнее и сложнее. Чем вероятнее это, тем лучше вы идете с OO-подходом.

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

Ответ 15

Я считаю, что Грэди Буч однажды сказал, что вы действительно много выиграете от ООП на 10000 + строках кода.

Тем не менее, я всегда шел OO-way. Даже для 200 линий. Это превосходный подход в долгосрочной перспективе, а накладные расходы - просто переоцененное оправдание. Все большие вещи начинаются с малого.

Ответ 16

Я всегда начинаю разрабатывать сверху вниз, а в верхних частях гораздо проще думать в терминах ООП. Но когда приходит время, чтобы закодировать некоторые небольшие специфические части, вы намного более продуктивны при простом программировании. ООП - это здорово при разработке и формировании проекта, так что может применяться парадигма divide-et-impera. Но вы не можете применять его во всех аспектах своего кода, так как это религия:)

Ответ 17

Если вы "думаете OO" при программировании, то я не уверен, что имеет смысл спросить "когда я должен вернуться к процедурному программированию?" Это эквивалентно заданию java-программистам, что они не могут сделать, потому что Java требует классов. (Ditto.NET languages).

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

Ответ 18

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

Вы хотите джунгли?

Ответ 19

В большинстве исследований установлено, что код OO более краток, чем процедурный код. Если вы посмотрите проекты, которые переписывали существующий код C на С++ (не то, что я обязательно советую, BTW), вы обычно видите сокращения в размере кода от 50 до 75 процентов.

Итак, ответ: всегда используйте OO!

Ответ 20

IMHO, долгосрочные преимущества ООП перевешивают время, сэкономленное в краткосрочной перспективе.

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

Ответ 21

Вы можете написать плохое программное обеспечение в обеих концепциях. Тем не менее, сложное программное обеспечение намного проще писать, понимать и поддерживать на языках OO, чем в процедурных. Я написал очень сложные ERP-приложения на языке процедур (Oracle PL/SQL), а затем переключился на OOP (С#). Это был и остается глоток свежего воздуха.

Ответ 22

Мои два цента...

Преимущества процедурного программирования

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

Чем больше процедурный код станет хорошим, тем ближе к функциональному. И преимущества FP хорошо известны.