ООП против ПП для алгоритмов

Question

Какая парадигма лучше подходит для разработки и анализа алгоритмов? Что быстрее? Потому что у меня есть предмет под названием «Разработка и анализ алгоритмов в университете», и у меня есть ограничение по времени для программ. ООП медленнее, чем программирование процедур? Или разница во времени не большая?

Answer 1

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

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

Answer 2

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

Ни OO, ни PP не являются «медленными», ни во время разработки, ни в исполнении программ - это разные подходы.

Answer 3

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

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

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

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

Answer 4

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

Answer 5

Я однажды адаптировал алгоритм поиска строки Кнут-Моррис-Пратт , чтобы у меня мог быть объект, который будет принимать символ за раз и возвращать состояние совпадения / отсутствия совпадения. Это был не простой перевод.

Answer 6

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

Answer 7

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

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

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

Answer 8

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

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

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

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

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

---

EDIT:

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

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

Answer 9

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

Answer 10

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

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