Для каких задач объектно-ориентированное программирование не является хорошим выбором? [закрыто]

19

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

Я был в ... ну, давайте назовем это разработкой программного обеспечения практически всю свою жизнь, и все это время, хотя ОО всегда был там (ну, большую часть времени), мне никогда не приходилось использовать «свои пути», ни изучать эту парадигму. Мы всегда использовали довольно простые программные структуры, подпрограммы / функции / модули, и, хотя это противоречит сегодняшним лучшим методам управления этими программами (программы до примерно 300 тыс. LOC, ничего слишком большого), никогда не оказывалось трудным, не говоря уже о невозможности.

Итак, я хотел бы спросить вас, какие проблемы сорта, для которых объектно-ориентированная парадигма не будет хорошим выбором? По сравнению с процедурным программированием?

ладья
источник
Также см. Stackoverflow.com/questions/178262/… .
С.Лотт

Ответы:

8

Объектно-ориентированное программирование - это процедурное программирование. То, что делает объектно-ориентированное ОО, как упоминает Роберт Харви в комментарии, заключается в том, что ОО абстрагирует данные особым образом (например, связывая функции, которые работают со структурой, с этой структурой).

Уильям Кук прекрасно объясняет разницу между объектами и абстрактными типами данных.

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

Фрэнк Шиарар
источник
5

Основная ценность ОО заключается в том, что он обеспечивает разделение между компонентами вашей системы, облегчая написание СУХОГО кода и адаптацию к конкретным типам изменений, которые вы планируете в своем проекте. Цена заключается в том, что он добавляет уровни косвенности, которые могут усложнить понимание кода, сделать его менее эффективным и трудным для изменения непредвиденными способами (способы, которые не обеспечиваются разделением вашего проекта). Таким образом, это пустая трата времени для любой подзадачи, в которой вам не нужна развязка, которую она обеспечивает. В частности, это пустая трата времени, если вы можете легко написать DRY-код без него и не ожидать каких-либо конкретных изменений требований, которые выиграли бы от сильной развязки, которую обеспечивает ОО.

dsimcha
источник
3
Разъединение - хороший побочный эффект хорошо выполненного ОО-программирования, но я бы сказал, что основным преимуществом ОО-программирования является организационная инкапсуляция функциональности.
Роберт Харви
1
@ Роберт Харви: У меня другая точка зрения на ту же реальность: для меня организационная инкапсуляция функциональности - это средство для получения разъединения, которое, в свою очередь, допускает возможность повторного использования.
Mouviciel
@ Роберт Харви: Связь и сплоченность - это два способа взглянуть на одну и ту же вещь, которая является своего рода местностью, где вы можете понять что-то без необходимости понимать слишком многое другое.
Дэвид Торнли
Я думаю, что часть разногласий заключается в том, что, IMHO, использование ОО означает, что вы широко используете полиморфизм и наследование, по крайней мере, интерфейсов. По моему определению ОО, например, структуры C # или D или использование только конечных / запечатанных классов, и никакие интерфейсы не будут рассматриваться как синтаксический сахар плюс несколько атрибутов управления доступом, а не как реальный ОО.
dsimcha 28.10.10
3

параллелизм: механизм блокировки кажется проблематичным; только некоторые очень хорошие разработчики работают над многопоточностью проектов

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

Belun
источник
+1 для аргумента блокировки - доказательства, по-видимому,
состоят
+1 за упоминание параллелизма. Концепция, похожая на объекты, но поддерживающая параллелизм, - это концепция актера. Действующие лица - это параллельные объекты, которые обмениваются данными посредством обмена асинхронными сообщениями.
Джорджио
То же самое по параллелизму; Я сделал заявление о том, что ОО, поощряя вас идентифицировать / поддерживать отдельные единицы состояния , на самом деле поощряет проблемы параллелизма.
user1172763
0

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

Основной алгоритм вроде qsort()использует абстракции для сравнения произвольных объектов. fread()использует интерфейс для абстрагирования от деталей потока и т. д.

С этой точки зрения мне трудно придумать какую-либо конкретную проблему, которая лучше решается с помощью подхода без ОО.

Мартин Викман
источник
0

Я думаю, что при построении систем, объединяющих другие системы через веб-интерфейс API (rest, xmlprc, plain curl / wget), вы можете писать OO-оболочки, но это явно просто удобство. Если используемый веб-сервис прост и состоит из одной или двух строк, то OO - это слишком много. Если, с другой стороны, вам придется обернуть сложный веб-интерфейс (например, Amazon AWS), то неплохо иметь библиотеку-обертку (например, boto в python для AWS).

Мысли?

Кристофер Махан
источник
0

Объектно-ориентированные языки PURE не подходят для многих случаев. Потому что есть некоторые критерии, которые нужно выполнить, чтобы быть чисто объектно-ориентированным языком. См.
Https://stackoverflow.com/questions/250062/what-is-meant-by-the-term-true-object-orientation/250098#250098

Но наиболее широко используемые языки программирования являются мультипарадигмальными. Они включают в себя множество функций, не связанных с OO, для решения различных проблем программирования и разработки. C ++, C #, Java или Ruby имеют функции, не связанные с OO. Таким образом, они могут столкнуться с проблемами, с которыми чисто ОО не справляется.

Gulshan
источник
0

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

Я обнаружил, что это полезный способ создания СУХОЙ модели, которая может четко представлять правила и поведение вашего приложения таким образом, который не связан с техническими проблемами (такими как использование базы данных, очереди сообщений или На самом деле это веб-приложение). Хорошая книга на эту тему - « Дизайн, управляемый доменом»

Здесь важно отметить, что упомянутые выше «сущности» не должны отображаться на объекты реального мира! Они могут представлять абстрактные части домена вашего приложения.

Итак, если это то, в чем хороша объектно-ориентированное программирование; что не хорошо? Ну, ничего, где модель предметной области не может быть выражена как объекты. Например, некоторые математические (статистические, логические и т. Д.) Или технические (например, компилятор) программы лучше выражаются в разных стилях. Я обнаружил, что для приложений бизнес-процессов сочетание ОО и пользовательских технологий DSL очень эффективно позволяет нам моделировать виды отношений и событий, которые происходят в бизнес-процессе. Для верификации программы и автоматической проверки корректности часто используется функциональный подход , потому что его чистые функции допускают более прямые математические рассуждения.

flamingpenguin
источник