Что означает «ООП скрывает государство»? [закрыто]

В одном из многочисленных выступлений против ООП на сайте cat-v.org я обнаружил отрывок Джо Армстронга, в котором было высказано несколько возражений против модели ООП, одним из которых было следующее:

Возражение 4 - Объекты имеют частное состояние

Государство является корнем всего зла. В особенности следует избегать функций с побочными эффектами.

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

Учитывая, что состояние существует в реальном мире, какие возможности должен обеспечить язык программирования для работы с состоянием?

OOPL говорят «скрыть состояние от программиста». Состояния скрыты и видны только через функции доступа. Обычные языки программирования (C, Pascal) говорят, что видимость переменных состояния контролируется правилами области видимости языка. Чистые декларативные языки говорят, что нет государства. Глобальное состояние системы переносится на все функции и выходит из всех функций. Такие механизмы, как монады (для FPL) и DCG (логические языки) используются, чтобы скрыть состояние от программиста, чтобы они могли программировать «как если бы состояние не имело значения», но иметь полный доступ к состоянию системы, если это необходимо.

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

Что именно подразумевается под этим? У меня очень мало низкого уровня или процедурного опыта, в основном ООП, так что, вероятно, это объясняет, насколько я незнаком с этим. И с более современной точки зрения, теперь, когда большая часть объектно-ориентированной истерии пройдена (по крайней мере, насколько я могу судить), насколько вы, ребята, думаете, насколько точен / актуален этот отрывок?

Спасибо за вашу помощь.

Что именно подразумевается под этим?

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

Как вы думаете, насколько точно / актуально этот отрывок?

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

В лучшем случае ООП работает как лучшее сочетание функционального программирования и процедурного - люди могут использовать класс «как если бы состояние не имело значения», потому что частное состояние, используемое для защиты инвариантов класса, скрыто, но имеет свободу использовать четко определенное публичное состояние класса, которое абстрагирует детали.

ООП затрудняет ли людям достижение этого лучшего случая? Возможно. «Школы Java» и вся школа «Форма / Круг / Прямоугольник» или «Автомобиль» имеют в Уилсе школу преподавания ОО, вероятно, виноват больше, чем сам подход. Современный ООП в значительной степени извлекает пользу из функционального программирования, поощряя неизменные объекты и чистые функции, в то же время препятствуя наследованию, чтобы упростить разработку классов, которые работают хорошо.

Рассуждать о системе будет сложно, если есть фрагменты изменяемого состояния, у которых нет ни одного явного «владельца». Это не означает, что объекты никогда не должны иметь изменяемое состояние, скорее, объекты, которые действительно имеют изменяемое состояние, не должны использоваться способами, где владение может быть неясным, и наоборот, объекты, которые необходимо будет свободно передавать без отслеживания владения, должны быть неизменным

На практике эффективное программирование часто требует, чтобы некоторые объекты имели изменяемое состояние; однако такое состояние должно быть ограничено неразделенными рабочими объектами. Рассмотрим IEnumerable/ IEnumeratorinterfaces в .NET: если коллекция реализует IEnumerable, она позволяет считывать элементы по одному за раз. Фактический процесс считывания коллекции часто требует отслеживания того, какие элементы были прочитаны (фрагмент изменяемого состояния), но такое состояние не содержится в реализации IEnumerable. Вместо этого IEnumerableпредоставляет вызываемый метод, GetEnumeratorкоторый будет возвращать объект, который реализует IEnumeratorи содержит достаточно состояния, чтобы позволить элементам считываться из коллекции. Однако тот факт, что объект содержит такое состояние, не создает проблем.если реализация объекта IEnumeratorне является общей .

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

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

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

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

Я лично хотел бы видеть следующий уровень, где люди научатся решать проблемы, рассматривая их лингвистически. Где они будут понимать концепцию предметно-ориентированных языков, как их легко сделать и позволить их созданию стать неотъемлемой частью решения проблем. Нельзя сказать, что структура данных - это язык. У людей должен быть этот навык языкового дизайна, чтобы они не просто неуклюжие.

Затем, на следующем уровне, я бы хотел, чтобы искусственный интеллект активизировался. Мне бы хотелось, чтобы программисты вышли за рамки байтов, потоков, таблиц виртуальных функций и CUDA, а также научились рассуждать, учиться и творить машины. Я знаю, что это продвинулось очень далеко в маленьких уголках поля, но далеко не достаточно широко.

Доступность не является функцией ООП, она специфична для таких реализаций, как Java и Microsoft dotNET. Основной особенностью, которая определяет ООП, является полиморфизм.

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

Такие сайты, как тот, на который вы ссылались, известны своими чрезвычайно жесткими мыслями и критикой новых технологий. Некоторые люди просто не понимают этого.