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

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

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

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

, Таким образом, ответ - всегда используют OO!

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

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

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

Я полагаю, что Grady Booch сказал однажды, что Вы действительно начинаете извлекать выгоду много из ООП в 10 000 + строки кода.

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

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

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

Мы все привыкли к идее алгоритмов, которые говорят нам, как объединить различные процедуры и структуры данных для выполнения общих задач. С другой стороны взгляд на Шаблоны разработки Банды Четыре для идей о том, как объединить объекты выполнить общие задачи.

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

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

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

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

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

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

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

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

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

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

Я думаю принцип DRY (не Повторяйте Себя), объединенный с немного Гибким хороший подход. Создайте свою программу, инкрементно запускающуюся с самой простой вещи, которая работает, затем добавляют опции один за другим и осуществляют рефакторинг Ваш код по мере необходимости, как Вы продвигаетесь.

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

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

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

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

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

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

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

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

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

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

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

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

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

Рассмотрим следующий сценарий: Ваш код не объектно-ориентированный. В вашей программе есть структуры данных и множество функций, которые работают со структурами данных. Каждая функция принимает структуру данных в качестве параметра и делает разные вещи в зависимости от поля «data_type» в структуре данных.

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

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

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

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

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

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

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

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

Хотите джунгли?

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

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

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

• Лука Карделли написал работу под названием "Плохие инженерные свойства объектно-ориентированных языков".

• Ричард Столлман написал в 1995 году: "Добавление ООП в Emacs не является очевидным улучшением; я использовал ООП при работе над оконными системами Lisp Machine, и я не согласен с обычным мнением, что это лучший способ программирования."

• Исследование Потока и др. не показало существенной разницы в производительности между ООП и процедурными подходами.

• Кристофер Дж. Дейт заявил, что критическое сравнение ООП с другими технологиями, в частности с реляционными, затруднено из-за отсутствия согласованного и строгого определения ООП. Предложена теоретическая основа ООП, которая использует ООП как своего рода настраиваемую систему типов для поддержки РСУБД.

• Александр Степанов предположил, что ООП предоставляет математически ограниченную точку зрения и назвал его "почти такой же мистификацией, как искусственный интеллект" (возможно, имея в виду проекты искусственного интеллекта и маркетинг 1980-х годов, которые иногда рассматриваются как чрезмерно усердные в ретроспективе).

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

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

• Ричард Мэнсфилд, автор и бывший редактор журнала COMPUTE!, утверждает, что "как и бесчисленные другие интеллектуальные причуды прошлых лет ("актуальность", коммунизм, "модернизм" и так далее - история пестрит ими), ООП будет с нами, пока в конце концов реальность не заявит о себе". Но учитывая то, как ООП в настоящее время пронизывает университеты и рабочие места, ООП вполне может оказаться долговечным заблуждением. Целые поколения индоктринированных программистов продолжают выходить из академии, приверженные ООП и ничему, кроме ООП, до конца своих дней.", а также цитируется высказывание "ООП для написания программы - это то же самое, что прохождение контроля в аэропорту для полета".