Из того, что я понимаю, ООП является наиболее часто используемой парадигмой для крупномасштабных проектов. Я также знаю, что некоторые более мелкие подмножества больших систем используют другие парадигмы (например, SQL, который является декларативным), и я также понимаю, что на более низких уровнях вычислений ООП не реально выполнимо. Но мне кажется, что обычно куски решений более высокого уровня почти всегда объединяются в ООП.
Существуют ли какие-либо сценарии, когда истинно не-ООП-парадигма на самом деле является лучше выбором для крупномасштабного решения? Или это неслыханное из этих дней?
Я задавался этим вопросом с тех пор, как начал изучать CS; легко понять, что ООП - это нирвана программирования, которая никогда не будет превзойдена.
По моему мнению, причина, по которой ООП используется настолько широко, - это не так много, что это правильный инструмент для работы. Я думаю, что более того, решение может быть описано клиенту таким образом, что они понимают.
АВТОМОБИЛЬ - АВТОМОБИЛЬ, у которого есть ДВИГАТЕЛЬ. Это программирование и реальный мир в одном!
Трудно понять все, что может поместиться в программировании и реальном мире настолько элегантно.
Linux - это крупномасштабный проект, который очень не OOP. И от него тоже нечего было бы выиграть.
Я думаю, что у OOP есть хорошее кольцо, потому что оно связано с хорошими практиками программирования, такими как инкапсуляция, скрытие данных, повторное использование кода, модульность et.c. Но эти добродетели отнюдь не уникальны для ООП.
Вы можете взглянуть на Эрланг, написанный Джо Армстронгом.
Википедия:
"Эрланг - это универсальный параллельный язык программирования и времени выполнения. Последовательное подмножество Эрланг - функциональный язык, со строгой оценкой, single назначение и динамическое типирование".
Джо Армстронг:
"Поскольку проблема с объектно-ориентированными языками являются получил всю эту неявную среду, которая они несут с собой. Вы хотел банан, но то, что вы получили, было горилла, держащая банан и целые джунгли."
Обещание ООП заключалось в повторном использовании кода и упрощении обслуживания. Я не уверен, что он доставлен. Я вижу такие вещи, как dot net, как те же, что и библиотеки C, которые мы использовали для разных поставщиков. Вы можете вызвать это повторное использование кода, если хотите. Что касается обслуживания, то плохой код - это плохой код. ООП не помогло.
Я самый большой поклонник ООП, и каждый день я занимаюсь ООП. Это самый естественный способ писать код, потому что он похож на реальную жизнь.
Хотя, я понимаю, что виртуализация ООП может вызвать проблемы с производительностью. Конечно, это зависит от вашего дизайна, языка и платформы, которую вы выбрали (системы, написанные на языках, основанных на сборке Garbage, таких как Java или С#, могут работать хуже, чем системы, написанные на С++, например).
Я думаю, что в системах реального времени процедурное программирование может быть более подходящим.
Обратите внимание, что не все проекты, претендующие на ООП, на самом деле являются ООП. Иногда большая часть кода является процедурной, или модель данных anemic и т.д....
Zyx, вы написали: "Большинство систем используют реляционные базы данных..."
Я боюсь, что нет такой вещи. Реляционной модели будет 40 лет в следующем году и до сих пор не реализован. Я думаю, вы имеете в виду "базы данных SQL". Вы должны прочитать что-либо Фабиан Паскаль, чтобы понять разницу между реляционными dbms и SQL dbms.
"... реляционная модель обычно выбирается из-за ее популярности"
Правда, это популярно.
"... доступность инструментов",
Увы, без основного инструмента необходимо: реализация реляционной модели.
",
Yup, реляционная модель имеет точную поддержку, я уверен, но она полностью не поддерживается реализацией dbms.
"и тот факт, что реляционная модель на самом деле является математическим понятием"
Да, это математическая концепция, но, не будучи реализована, она в значительной степени ограничивается башнями из слоновой кости. Теория струн также является математической концепцией, но я бы не реализовал с ней систему.
На самом деле, несмотря на то, что это математическая концепция, это, конечно, не наука (как в информатике), потому что ей не хватает первого требования какой-либо науки: она фальсифицирована: нет реализации реляционных dbms, против которых мы может проверить свои претензии.
Это чистое масло змеи.
"... вопреки ООП.
И вопреки ООП реляционная модель никогда не была реализована.
Купить книгу по SQL и получить продуктивность.
Оставьте реляционную модель непродуктивным теоретикам.
См. this и this. Очевидно, вы можете использовать С# с пятью различными парадигмами программирования, С++ с тремя и т.д.
Построение программного обеспечения не связано с фундаментальной физикой. Физика стремится описать реальность с помощью парадигм, которые могут быть оспорены новыми экспериментальными данными и/или теориями. Физика - это наука, которая ищет "правду", так, как это делает разработка ПО.
Разработка программного обеспечения - это бизнес. Вам нужно быть результативным, т.е. Достичь некоторых целей, за которые кто-то заплатит деньги. Парадигмы используются, потому что они полезны для эффективно производить программное обеспечение. Вам не нужно, чтобы все согласились. Если я буду делать ООП и это хорошо работает для меня, мне все равно, если бы "новая" парадигма потенциально была бы на 20% полезна мне, если бы у меня было время и деньги, чтобы изучить ее, а затем переосмыслить всю структуру программного обеспечения. m работает и редизайн с нуля.
Кроме того, вы можете использовать другую парадигму, и я все равно буду счастлив, точно так же, как я могу заработать деньги в японском ресторане, и вы можете зарабатывать деньги в мексиканском ресторане питания по соседству. Мне не нужно обсуждать с вами, является ли японская еда лучше, чем мексиканская еда.
Я сомневаюсь, что ООП уйдет в ближайшее время, это просто подходит для наших проблем и умственных моделей слишком хорошо.
То, что мы начинаем видеть, - это подход с несколькими парадигмами, при этом декларативные и функциональные идеи включаются в объектно-ориентированные проекты. Хорошим примером этого являются большинство новых языков JVM (JavaFX, Scala, Clojure и т.д.), А также LINQ и F # на платформе .net.
Важно отметить, что я не говорю о замене OO здесь, а о его дополнении.
JavaFX показал, что декларативный решение выходит за рамки SQL и XSLT, и может также использоваться для связывания свойства и события между визуальными компоненты в графическом интерфейсе
Для отказоустойчивости и высокой параллельные системы, функциональные программирование очень хорошо подходит, как продемонстрировано Ericsson AXD301 (запрограммировано с использованием Erlang)
Итак... поскольку concurrency становится более важным, и FP становится более популярным, я думаю, что языки, не поддерживающие эту парадигму, пострадают. Это включает в себя многие, которые в настоящее время популярны, такие как С++, Java и Ruby, хотя JavaScript должен справляться очень хорошо.
Использование OOP упрощает управление кодом (как в случае изменения/обновления/добавления новых функций) и понимает. Это особенно актуально для крупных проектов. Поскольку модули/объекты инкапсулируют свои данные и операции над этими данными, проще понять функциональность и общую картину.
Преимущество ООП заключается в том, что легче обсуждать (с другими разработчиками/менеджером/клиентом) LogManager или OrderManager, каждый из которых включает в себя определенные функции, а затем описывает "группу методов, которые выгружают данные в файл" и "методы, которые отслеживают детали заказа".
Поэтому я предполагаю, что ООП особенно полезен для крупных проектов, но всегда появляются новые концепции, поэтому в будущем нужно искать новые вещи, оценивать и поддерживать то, что полезно.
Людям нравится думать о разных вещах как о "объектах" и классифицировать их, поэтому нет сомнений в том, что ООП настолько популярен. Однако есть некоторые области, где ООП не приобрела большую популярность. Большинство систем используют реляционные базы данных, а не объективные. Даже если у вторых есть некоторые заметные записи и лучше для некоторых типов задач, реляционная модель выбирается из-за ее популярности, доступности инструментов, поддержки и того факта, что реляционная модель на самом деле является математической концепцией, вопреки ООП.
Другая область, где я никогда не видел ООП, - это процесс создания программного обеспечения. Все сценарии конфигурации и создания являются процедурными, частично из-за отсутствия поддержки ООП в языках оболочки, частично потому, что ООП слишком сложна для таких задач.