Когда объектно-ориентированное не является правильным решением?

Question

В последнее время я столкнулся с некоторыми мнениями о том, что объектно-ориентированное проектирование / программирование не всегда должно использоваться.
Знаете ли вы некоторые варианты использования, которые не принесут пользы и не должны использовать объектно-ориентированный дизайн?

Например: есть некоторые проблемы (проблемы), которые выиграют от АОП.

Answer 1

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

Примерами проблемных областей, в которых лучше подходят другие языковые парадигмы, являются запросы к базе данных (SQL) , экспертные системы (Prolog, CLIPS и т. Д.) или Статистические вычисления ( R) . * +1011 *

Answer 2

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

Answer 3

Межсекторальные проблемы извлекают выгоду из Аспектно-ориентированного программирования (АОП). Под междисциплинарным пониманием я подразумеваю функциональные возможности, которые могут принести пользу различным частям приложения и которые на самом деле не принадлежат конкретному объекту. Ведение журнала обычно приводится в качестве примера. Безопасность может быть другой. Например, почему объект Person должен знать что-либо о ведении журнала или кому должен быть разрешен доступ к нему?

Answer 4

Тот, который легко приходит на ум ... Базы данных и веб-приложения.
В таком сценарии, имеет больше смысла соответствовать принятой структуре ... вместо того, чтобы получить хороший дизайн ООП. например если вам нужно выполнить какой-то сложный запрос с помощью JOIN и ORDER BYs. SQL будет пнуть задницу объекта.

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

Answer 5

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

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

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

Answer 6

ООП и АОП не являются взаимоисключающими, они дополняют друг друга.

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

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

Answer 7

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

Answer 8

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

Answer 9

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

Answer 10

Я бы посоветовал вам посетить Википедию и прочитать их статьи о различных типах языков программирования.

Сказать, что тип программирования "недостаточно хорош", не имеет никакого смысла. У каждого типа есть цель. Вы не можете сравнить их. Они не созданы для того, чтобы делать то же самое.