ООП по сравнению с PP для алгоритмов

Я думаю, что Функциональное программирование приведет к более чистой реализации алгоритмов.

Сказав это, вы не должны видеть большой разницы, какой бы подход вы ни выбрали. Алгоритм может быть выражен на любом языке или парадигме разработки.

Обновление : (следующие комментарии)

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

Разница (во времени выполнения) в лучшем случае незначительна.

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

Объектно-ориентированное программирование абстрагирует от программиста многие детали низкого уровня. Он разработан с целью

• , чтобы упростить написание и чтение (и понимание) программ
• , чтобы программы были более похожи на реальный мир (и, следовательно, были более легкими для понимания).

В процедурном программировании не так много абстракций, как объекты, методы, виртуальные функции и т. Д.

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

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

РЕДАКТИРОВАТЬ:

Мне приходит в голову интересный анекдот: в классах Microsoft Foundation передача сообщений от одного объекта к другому была реализована с использованием макросов, которые выглядели как BEGIN_MESSAGE_MAP () и END_MESSAGE_MAP (), и причина была в том, что это было быстрее, чем использование виртуальных функций.

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

Я предполагаю, что разница не настолько велика, чтобы о ней беспокоиться, и ограничение по времени должно позволять использовать более медленный язык, поскольку используемый алгоритм будет важным. Цель ограничения по времени должна быть ИМО чтобы вы не использовали, например, алгоритм O (n ³ ), когда есть O (n log n)

Стив314 хорошо сказал. ООП больше касается шаблонов проектирования и организации больших приложений.Это также позволяет лучше справляться с неизвестными, что отлично подходит для пользовательских приложений. Однако, анализируя алгоритмы, вы, скорее всего, будете думать функционально о том, что хотите делать. В этом случае я бы придерживался более простого PP и не пытался создать полностью объектно-ориентированный дизайн, когда вам важен алгоритм. Я бы хотел работать с C или Matlab (в зависимости от того, насколько математически сложен алгоритм). Только мое мнение по этому поводу.

Чтобы сделать написание кода простым и менее подверженным ошибкам, вам нужен язык, поддерживающий универсальные шаблоны, например C ++ с STL или Java с Java Collections Framework. Если вы реализуете алгоритм с соблюдением крайнего срока, вы можете сэкономить время, не снабдив свой алгоритм красивым O-O или универсальным интерфейсом, поэтому создавая код, который вы пишете, полностью процедурный.

Для повышения эффективности во время выполнения вам, вероятно, лучше всего писать все на процедурном языке C - см., Например,примеры из «Практики программирования» - но это займет намного больше времени, и вы с большей вероятностью сделаете ошибки. Это также предполагает, что все необходимые вам строительные блоки доступны в наиболее актуальном и эффективном виде в процедурном C, что в наши дни является довольно распространенным предположением. Скорее всего, использование STL или JFC на практике сэкономит вам время процессора, а также время разработки.

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

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

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

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

Алгоритмы IMO существуют отдельно от вопроса OO или PP.

Ни ОО, ни ПП не являются "медленными", ни по времени проектирования, ни по производительности программы, это разные подходы.

Для проектирования, анализа и разработки: определенно ООП. Оно было торжественно изобретено на благо проектировщиков и разработчиков. Для выполнения программы: иногда ПП более эффективен, но часто компилятор сводит ООП к простому ПП, делая их эквивалентными.

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