Значительные претенденты на ООП

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

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

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

Ответ 1

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

АВТОМОБИЛЬ - АВТОМОБИЛЬ, у которого есть ДВИГАТЕЛЬ. Это программирование и реальный мир в одном!

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

Ответ 2

Linux - это крупномасштабный проект, который очень не OOP. И от него тоже нечего было бы выиграть.

Я думаю, что у OOP есть хорошее кольцо, потому что оно связано с хорошими практиками программирования, такими как инкапсуляция, скрытие данных, повторное использование кода, модульность et.c. Но эти добродетели отнюдь не уникальны для ООП.

Ответ 3

Вы можете взглянуть на Эрланг, написанный Джо Армстронгом.

Википедия:

"Эрланг - это универсальный параллельный язык программирования и времени выполнения. Последовательное подмножество Эрланг - функциональный язык, со строгой оценкой, single назначение и динамическое типирование".

Джо Армстронг:

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

Ответ 4

Обещание ООП заключалось в повторном использовании кода и упрощении обслуживания. Я не уверен, что он доставлен. Я вижу такие вещи, как dot net, как те же, что и библиотеки C, которые мы использовали для разных поставщиков. Вы можете вызвать это повторное использование кода, если хотите. Что касается обслуживания, то плохой код - это плохой код. ООП не помогло.

Ответ 5

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

Хотя, я понимаю, что виртуализация ООП может вызвать проблемы с производительностью. Конечно, это зависит от вашего дизайна, языка и платформы, которую вы выбрали (системы, написанные на языках, основанных на сборке Garbage, таких как Java или С#, могут работать хуже, чем системы, написанные на С++, например).

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

Ответ 6

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

Ответ 7

Zyx, вы написали: "Большинство систем используют реляционные базы данных..."

Я боюсь, что нет такой вещи. Реляционной модели будет 40 лет в следующем году и до сих пор не реализован. Я думаю, вы имеете в виду "базы данных SQL". Вы должны прочитать что-либо Фабиан Паскаль, чтобы понять разницу между реляционными dbms и SQL dbms.

"... реляционная модель обычно выбирается из-за ее популярности"

Правда, это популярно.

"... доступность инструментов",

Увы, без основного инструмента необходимо: реализация реляционной модели.

Yup, реляционная модель имеет точную поддержку, я уверен, но она полностью не поддерживается реализацией dbms.

"и тот факт, что реляционная модель на самом деле является математическим понятием"

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

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

Это чистое масло змеи.

"... вопреки ООП.

И вопреки ООП реляционная модель никогда не была реализована.

Купить книгу по SQL и получить продуктивность.

Оставьте реляционную модель непродуктивным теоретикам.

Ответ 8

См. this и this. Очевидно, вы можете использовать С# с пятью различными парадигмами программирования, С++ с тремя и т.д.

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

Разработка программного обеспечения - это бизнес. Вам нужно быть результативным, т.е. Достичь некоторых целей, за которые кто-то заплатит деньги. Парадигмы используются, потому что они полезны для эффективно производить программное обеспечение. Вам не нужно, чтобы все согласились. Если я буду делать ООП и это хорошо работает для меня, мне все равно, если бы "новая" парадигма потенциально была бы на 20% полезна мне, если бы у меня было время и деньги, чтобы изучить ее, а затем переосмыслить всю структуру программного обеспечения. m работает и редизайн с нуля.

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

Ответ 9

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

То, что мы начинаем видеть, - это подход с несколькими парадигмами, при этом декларативные и функциональные идеи включаются в объектно-ориентированные проекты. Хорошим примером этого являются большинство новых языков JVM (JavaFX, Scala, Clojure и т.д.), А также LINQ и F # на платформе .net.

Важно отметить, что я не говорю о замене OO здесь, а о его дополнении.

JavaFX показал, что декларативный решение выходит за рамки SQL и XSLT, и может также использоваться для связывания свойства и события между визуальными компоненты в графическом интерфейсе
Для отказоустойчивости и высокой параллельные системы, функциональные программирование очень хорошо подходит, как продемонстрировано Ericsson AXD301 (запрограммировано с использованием Erlang)

Итак... поскольку concurrency становится более важным, и FP становится более популярным, я думаю, что языки, не поддерживающие эту парадигму, пострадают. Это включает в себя многие, которые в настоящее время популярны, такие как С++, Java и Ruby, хотя JavaScript должен справляться очень хорошо.

Ответ 10

Использование OOP упрощает управление кодом (как в случае изменения/обновления/добавления новых функций) и понимает. Это особенно актуально для крупных проектов. Поскольку модули/объекты инкапсулируют свои данные и операции над этими данными, проще понять функциональность и общую картину.

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

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

Ответ 11

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

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