Когда Объектно-ориентировано не правильное решение? [закрытый]

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

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

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

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

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

Любое время Вы не можете думать о серьезном основании для OO, является хорошим временем для предотвращения его. (Звучит остроумным, но я серьезен.)

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

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

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

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

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

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

Что касается OO, существует, конечно, случай, где это менее apllicable. Если бы не было всего, что мы имели бы, языки OO. Для задач чисто перемалывания чисел многие люди все еще предпочитают Фортран. Функциональные языки полезны, когда Вы имеете дело с параллелизмом и параллелизмом.

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

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

Тот, который легко приходит на ум... Веб-приложения базы-данных-y.
В таком сценарии имеет больше смысла соответствовать принятой платформе.. вместо eek хороший дизайн ООП. например, если необходимо сделать некоторый сложный запрос с СОЕДИНЕНИЕМ и ЗАКАЗАТЬ BYs.. SQL ударит объектный торец.

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

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

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

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