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

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

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

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

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

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

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

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

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

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

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

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

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

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

Мысли?

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

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

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

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

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

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