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

11

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

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

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

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

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

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

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

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

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

Джейк
источник
3
рекомендуемое чтение: Обсудите этот $ {блог}
комнат
1
Если вы спросите меня, в статье, на которую вы ссылаетесь, приводятся несколько довольно плохих аргументов (не говоря уже о качестве написания). Я бы не стал вкладывать слишком много в то, что он говорит.
Бенджамин Ходжсон
1
Ба. Я все больше и больше думаю, что вся эта «неизменная» вещь - хорошая идея, которая начинает вонять религией.
Роб
3
Джо Армстронг публично признал, что его возражения против ОО были основаны на серьезном недопонимании того, что такое ОО. Теперь он понял, что Erlang на самом деле является глубоко объектно-ориентированным языком (на самом деле, он может быть наиболее объектно-ориентированным языком в массовом использовании).
Йорг W Mittag
9
Более подробно об этом: первый захват archive.org разглагольствования Джо Армстронга относится к апрелю 2001 года. Джо написал свою диссертацию в 2003 году. Во время написания своей диссертации он узнал много нового об ОО и понял, что стал жертвой распространенное заблуждение, что ОО как-то связано с изменяемым состоянием (это не так, изменяемое состояние полностью ортогонально). С тех пор он признал, что его критика ОО была неправильной и что по иронии судьбы Эрланг на самом деле является объектно-ориентированным языком (у него есть сообщения, у него есть объекты, которые он называет процессами, у него есть инкапсуляция).
Йорг Миттаг

Ответы:

32

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

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

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

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

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

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

Telastyn
источник
3
Согласитесь искренне в целом немного о "школах java", вообще не нравится, хе. Большое спасибо, я бы проголосовал, если бы мог.
Джейк
2
Просто чтобы быть точным: монады вообще не скрывают состояние, некоторые монады делают (например, IO). Смотрите среди других stackoverflow.com/questions/2488646/...
thSoft
2
+1. Это гораздо более взвешенный и нюансированный анализ, чем статья, на которую ссылался опрашивающий
Бенджамин Ходжсон,
2
Джо Армстронг публично признал, что его возражения против ОО были основаны на серьезном недопонимании того, что такое ОО. Теперь он понял, что Erlang на самом деле является глубоко объектно-ориентированным языком (на самом деле, он может быть наиболее объектно-ориентированным языком в массовом использовании).
Йорг W Mittag
2
Jorg - не могли бы вы опубликовать ссылку на продолжение Джо? Мне было бы очень интересно прочитать это. И @radarbob, отлично!
user949300
2

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

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

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

Supercat
источник
Отличное различие между тем, что должно быть неизменным, и тем, что может иметь изменяемое состояние. Прочитав это, я понял, что мои более поздние графы объектов (более неизменные, чем они были) в основном следуют этому руководству, но при этом оно не указано так же ясно, как вы. Это хорошее умеренное противоядие от «изменчивого состояния - это всегда зло» фигня, которую вы иногда слышите.
Майк поддерживает Монику
@Mike: я думаю, что реальная проблема заключается в том, что все ссылки на объекты в Java и .NET полностью разнородны; любой код, который получает или получает ссылку на объект, может делиться им с любым другим кодом без ограничений. Ни одна из структур не имеет понятия не подлежащего разделению эталонного поля; структуры и ссылки в .NET близки, но они довольно ограничены с точки зрения того, что они могут делать или что они могут препятствовать выполнению внешнего кода. В любом случае, я хотел бы предложить фундаментальное высказывание в отношении изменчивого состояния: в 12:57 объект может одновременно представлять ...
суперкат
... текущее состояние объекта реального мира и состояние объекта в 12:57. Если реальное состояние объекта изменится, он больше не сможет представлять оба объекта. Иногда необходимо, чтобы объект продолжал представлять состояние 12:57, а иногда - текущее состояние. Однако взаимосвязь между состоянием 12:57 утра и текущим состоянием не может сохраняться, если текущее состояние изменяется.
суперкат
0

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

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

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

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

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

Майк Данлавей
источник
1
«Если он действительно мощный, он может симулировать язык ассемблера», - вы меняете определение powerfulпрямо здесь. Когда другие говорят powerful, они говорят о том, насколько хорошо это позволяет программистам абстрагироваться , что является другой историей, чем вычислительная мощность .
Фил
@Phil: аннотация - еще одно из этих слов :)
Майк Данлавей
Неа. Вы говорили о словах. Я говорил об идеях. Ваше второе и третье употребление слова powerозначают разные вещи. Пожалуйста, не вводите в заблуждение.
Фил
Кстати, если вам интересно, посмотрите Racket , который несколько близок к подходу, о котором вы говорите в четвертом абзаце (позволяя программистам довести язык до уровня их проблемы, вместо того, чтобы заставлять их доводить проблему до фиксированный в языке набор конструкций). Он выходит далеко за рамки классического Lisp / Scheme, на случай, если у кого-то возникнет такое впечатление при первом взгляде на него.
Фил
0

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

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

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

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