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

Не достаточно хорошо? Я не знаю, смогу ли я привести пример этого, но я знаю, что некоторые ДЕЙСТВИТЕЛЬНО простые приложения могут не увидеть никаких «преимуществ» в начале использования полностью объектно-ориентированной модели проектирования. Однако, если это что-то действительно процедурное и тривиальное, в конце концов, может потребоваться повторное посещение.

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

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

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

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

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

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

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

Сказать, что какой-то тип программирования «недостаточно хорош», не имеет никакого смысла. У каждого типа есть цель. Их нельзя сравнивать. Их не заставляют делать то же самое.

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

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

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

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

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

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

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

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

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

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

Объектно-ориентированное программирование - хорошее решение, если вы делаете хороший дизайн.

Вторя Найджелу, SQL кажется почти неявно несовместимым с любыми абстракциями (включая подзапросы и функции).

Что ж, ООП не особо ортогонален чему-либо (кроме, возможно, других способов получения полиморфизма), так что ... э-э ... что угодно.