Действительно ли объектно-ориентированное программирование моделирует реальный мир? [закрыто]

Я часто повторял, что объектно-ориентированное программирование основано на моделировании реального мира, но так ли это?

Мне кажется, что это не относится ни к чему вне бизнес-уровня. Мои классы GUI / классы доступа к данным ничего не моделируют в реальном мире. Даже на уровне моего бизнеса у меня есть классы, такие как наблюдатели, менеджеры, фабрики и т. Д., Которые не являются объектами реального мира. Я пытаюсь спроектировать свои классы, чтобы использовать преимущества таких вещей, как инкапсуляция, но инкапсулирован ли реальный мир?

Хотя некоторые объекты, которые я создаю, моделируют объекты реального мира, разве код предварительной ООП не сделает то же самое? Я сомневаюсь, что ОО был первым, кто включил такие концепции, как Customer, в свои базы кода. Но ОО на самом деле о том, как моделировать вещи, и этот метод моделирования не кажется мне вдохновленным реальным миром.

Итак: действительно ли объектно-ориентированное программирование моделирует реальный мир?

Нет, совсем нет.

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

Модели любого типа не полностью моделируют реальный мир.

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

То, о чем вы говорите (наблюдатели, менеджеры, фабрики и т. Д.), - это инфраструктура, которая поможет вам правильно составить абстракцию и поддержать необходимые функции, такие как постоянство.

В любом случае, что такое модель?
Модель - это упрощенное представление, используемое для объяснения работы реальной системы или события.

Есть ли объектно - ориентированное программирование позволяет моделировать реальный мир?

Определенно да

Практически невозможно смоделировать систему в точном соответствии с реальным миром.

Всегда ли мне нужно моделировать программное обеспечение именно после реального мира?

НЕТ

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

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

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

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

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

... Мир более богат, чем то, что можно выразить с помощью объектно-ориентированного синтаксиса.

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

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

источник цитаты: Виктория Лившиц, Следующий шаг в программировании

Да, ОО часто можно использовать для моделирования объектов реального мира.

Даже на уровне моего бизнеса у меня есть классы, такие как наблюдатели, менеджеры, фабрики и т. Д., Которые не являются объектами реального мира.

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

Чтобы инкапсулировать сущность, мы можем смоделировать эту сущность после ее реального аналога. Например, если у нас есть гитара, то класс гитары инкапсулирует поведение и свойства реальной гитары. Мы можем далее абстрагировать гитару как, скажем, IInventoryItemчтобы воспользоваться возможностью повторного использования кода через полиморфизм и наследование.

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

Это не означает, что ОО должен моделировать реальный мир, и что это всегда самое оптимальное решение для этого. Просто, как правило, «ОО моделирование реального мира» имеет смысл.

Это зависит от того, о каком реальном мире ты говоришь.

Хорхе Луис Борхес написал историю «Tlön, Uqbar, Orbis Tertius», где один из жителей-жителей, похоже, воспринимает свой реальный мир совершенно по-другому:

[...] люди воображаемого Тлона [...] придерживаются крайней формы беркелевского идеализма, отрицая реальность мира. Их мир понимается «не как совпадение объектов в пространстве, а как неоднородная серия независимых действий». На одном из воображаемых языков Тлона нет существительных. Его центральными единицами являются «безличные глаголы, определяемые односложными суффиксами или префиксами, имеющими силу наречий». Борхес перечисляет тлёничский эквивалент «лунной розы над водой»: hlör u fang axaxaxas mlö, что в буквальном смысле означает «вверх за восходящим спутником». [...] На другом языке Тлона «основной единицей является не глагол, а односложное прилагательное», которое в комбинации двух или более образует существительное: «луна» становится «круглым воздушным светом на темный "или"

(скопировано из википедии artice о книге)

Для меня дело не столько в том, что мир может восприниматься иначе, чем мы, что является своего рода клише, но в том, что восприятие самой структуры реальности зависит от языка, на котором мы говорим, будь то естественный или язык программирования. Tlönese может быть очень доволен Lisp и может видеть Java (AKA The Kingdom Of Nouns ) очень неестественным, в то время как большинство программистов-терранов склонны предпочитать объектно-ориентированные языки по сравнению с функциональными языками. Мне нравятся оба стиля, так как я думаю, что это в основном вопрос перспективы. Некоторые проблемы лучше всего решать с помощью функциональных, другие - с помощью методов объектно-ориентированного программирования. Хороший программист всегда смотрит на сложную проблему с разных сторон, прежде чем попытается найти решение. Или, как сказал Алан Кей: Точка зрения стоит 80 баллов IQ .

Итак, мой ответ на ваш вопрос: о каком реальном мире вы говорите? И как?

Хотя некоторые объекты, которые я создаю, моделируют объекты реального мира, разве код предварительной ООП не сделает то же самое?

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

Я видел, как это часто повторяется, объектно-ориентированное программирование основано на моделировании реального мира, но так ли это?

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

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

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

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

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

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

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

Я видел, как это часто повторяется, объектно-ориентированное программирование основано на моделировании реального мира, но так ли это?

Мне кажется, что это не относится ни к чему вне бизнес-уровня.

Нет. Как вы указываете, многие вещи, «смоделированные» в языке ООП, являются абстрактными понятиями, такими как очереди сообщений, контроллеры и стеки.

Даже на уровне вашего бизнеса вы все еще не моделируете «реальный мир». Предположим, у вас есть класс сотрудников. Сотрудники - это также Люди, которые также являются Млекопитающими, которые также являются Животными, которые также ... (зевают) Сотрудники имеют любимые цвета, они носят определенную одежду и верят определенным вещам. Короче говоря, в реальном мире существует огромная сложность, которую мы даже не пытаемся охватить в большинстве программ.

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

Следовательно, модели не должны пытаться (или притворяться) полностью представлять «реальный мир».

Хотя некоторые объекты, которые я создаю, моделируют объекты реального мира, разве код предварительной ООП не сделает то же самое? Я сомневаюсь, что ОО был первым, кто включил такие концепции, как Customer, в свои базы кода.

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

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

Самое большое различие между ООП и не-ООП заключается в том, что ООП связывает код с данными. Так что вместо вызова кода вот так:

verb(noun);

мы делаем это вместо этого:

noun->verb();

Хотя это может показаться грамматическим отличием, на самом деле это различие мышления. Мы говорим объектам, что делать, и, как правило, не волнует, каково внутреннее состояние или работа объекта. При описании объекта нам нужно только описать его открытый интерфейс, чтобы работать с ним.

Действительно ли объектно-ориентированное программирование моделирует реальный мир?

Не полностью.

Ну, в реальном мире мы сталкиваемся с реальными проблемами. Мы хотим решить эту проблему, используя парадигму, которая копирует систему, которую мы хотим построить, которая становится моделью.

Например, если проблема связана с приложением «Корзина», у нас есть разные объекты, такие как

1. Продукт, который является абстрактным термином, который может иметь несколько членов, таких как Книги, Гаджеты, Автомобили, которые снова могут быть разделены.

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

3. Налог считается на основе того, был ли продукт импортирован вместе с налоговыми критериями.

4. Пользователь может иметь корзину с перечнем товаров и т. Д.

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

Я думаю, что вы слишком много читаете о том, что должно быть очень прозаическим, историческим утверждением. Многие идеи ОО-программирования, классов, полиморфизма, виртуальных функций и т. Д. Были внедрены на языке Simula еще в 1960-х годах (http://en.wikipedia.org/wiki/Simula). Как следует из названия, Simula был разработан, чтобы быть языком для написания симуляций. Так исторически, да, идеи ОО были введены в попытке смоделировать «реальный мир». Преуспевают ли они больше чем другие стили, вопрос дебатов.

Хотя некоторые объекты, которые я создаю, моделируют объекты реального мира, разве код предварительной ООП не сделает то же самое?

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

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

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

Но ОО на самом деле о том, как моделировать вещи, и этот метод моделирования не кажется мне вдохновленным реальным миром.

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

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

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

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

Статья Википедии по этому вопросу хорошо подводит итог:

Моделирование и отношения реального мира
ООП можно использовать для связи объектов и процессов реального мира с цифровыми аналогами. Однако не все согласны с тем, что ООП облегчает прямое картирование в реальном мире (см. Раздел «Негативная критика») или что картирование в реальном мире является даже достойной целью; Бертран Мейер утверждает в «Построении объектно-ориентированного программного обеспечения» [21], что программа - это не модель мира, а модель какой-то части мира; «Реальность - двоюродный брат двоюродного брата».

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

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

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

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

Независимо от того, используете ли вы ОО или функциональные подходы, ваша программа должна что- то делать , не так ли? Весь смысл программы состоит в том, чтобы продемонстрировать определенное поведение с определенным набором стимулов. Так что причины того, что программы существуют вообще, в том, что они что- то делают . Ключевое слово здесь - поведение .

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

Пока что ничего из этого не говорило об ОО, не так ли? Давайте сделаем это сейчас.

Как только инженер понимает требования (поведенческие, AQA, ограничения и т. Д.), Возникает вопрос: как мне организовать свой код так, чтобы он делал все, что ему нужно было делать, и в то же время демонстрировал качества, необходимые для полезной программы? Объектно-ориентированное программирование - это стратегия организации функциональности вашей программы в единые модули взаимодействующих объектов. Функциональное программирование - это просто еще одна стратегия для организации функциональности вашей программы, и это происходит по-другому. Обе стратегии имеют свои сильные и слабые стороны.

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

Но возвращаясь к ОО, вы теперь можете видеть, что он не обязательно моделирует «реальный мир»; он организует поведение вашей программы так, чтобы она могла демонстрировать качества, необходимые для достижения любого количества бизнес-целей. Такие методы, как TDD, DDD и BDD - это способы, с помощью которых мы узнаем, как лучше всего организовать наши объекты. В таких книгах, как « Принципы, шаблоны и практики» , « Растущее объектно-ориентированное программное обеспечение, ориентированное на тесты» , « Спецификация на примере» и « Доменно-управляемый дизайн», изложены теория и практика объектно-ориентированной ориентации с акцентом на поведенческий дизайн.

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

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

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

Тем не менее, есть гораздо лучшие приближения реального мира, которые известны под термином «доменно-специфические языки» ( DSL ). Например, Boo предоставляет вам возможность писать понятный человеку код почти на простом английском языке (пример из статьи ).

apply_discount_of 5.percent:
         when order.Total > 1000 and customer.IsPreferred
         when order.Total > 10000

suggest_registered_to_preferred:
         when order.Total  > 100 and not customer.IsPreferred

Другим примером могут быть автоматизированные системы приемочного тестирования, основанные на языке корнишонов .

Feature: Some terse yet descriptive text of what is desired
    In order to realize a named business value
    As an explicit system actor
    I want to gain some beneficial outcome which furthers the goal

Scenario: Some determinable business situation
    Given some precondition
        And some other precondition
    When some action by the actor
        And some other action
        And yet another action
    Then some testable outcome is achieved
        And something else we can check happens too

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