Параллели ДОТУ с ООП (Объектно-ориентированное программирование)

В очередной раз прихожу к выводу, что математикам и программистам легче понять ДОТУ. Тот уровень абстракции, на котором приходится работать так и подталкивает к пониманию базовых категорий. Начну с небольшого фрагмента из книги «Философия Java»
Развитие абстракции
Все языки программирования построены на абстракции. Возможно, трудность решаемых задач напрямую зависит от типа и качества абстракции. Под словом «тип» я имею в виду: «Что конкретно мы абстрагируем?» Язык ассемблера есть небольшая абстракция от компьютера, на базе которого он работает. Многие так называемые «командные» языки, созданные вслед за ним (такие, как Fortran, BASIC и C), представляли собой абстракции следующего уровня. Эти языки обладали значительным преимуществом по сравнению с ассемблером, но их основная абстракция по-прежнему заставляет думать вас о структуре компьютера, а не о решаемой задаче. Программист должен установить связь между моделью машины (в «пространстве решения», которое представляет место, где реализуется решение, — например, компьютер) и моделью задачи, которую и нужно решать (в «пространстве задачи», которое является местом существования задачи — например, прикладной областью). Для установления связи требуются усилия, оторванные от собственно языка программирования; в результате появляются программы, которые трудно писать и тяжело поддерживать. Мало того, это еще создало целую отрасль «методологий программирования».
 
Альтернативой моделированию машины является моделирование решаемой задачи. Ранние языки, подобные LISP и APL, выбирали особый подход к моделированию окружающего мира («Все задачи решаются списками» или «Алгоритмы решают все» соответственно). PROLOG трактует все проблемы как цепочки решений. Были созданы языки для программирования, основанного на системе ограничений, и специальные языки, в которых программирование осуществлялось посредством манипуляций с графическими конструкциями (область применения последних оказалась слишком узкой). Каждый из этих подходов хорош в определенной области решаемых задач, но стоит выйти из этой сферы, как использовать их становится затруднительно.
 
Объектный подход делает шаг вперед, предоставляя программисту средства для представления задачи в ее пространстве. Такой подход имеет достаточно общий характер и не накладывает ограничений на тип решаемой проблемы. Элементы пространства задачи и их представления в пространстве решения называются «объектами». (Вероятно, вам понадобятся и другие объекты, не имеющие аналогов в пространстве задачи.) Идея состоит в том, что программа может адаптироваться к специфике задачи посредством создания новых типов объектов так, что во время чтения кода, решающего задачу, вы одновременно видите слова, ее описывающие. Это более гибкая и мощная абстракция, превосходящая по своим возможностям все, что существовало ранееНекоторые разработчики языков считают, что само по себе объектно-ориентированное программирование не является достаточным для решения всех задач программирования, и выступают за сочетание различных парадигм программирования в одном языке. Такие языки называют мультипарадигма́льными (multiparadigm). Смотрите книгу Тимоти Бадда Multiparadigm Programming in Leda (Addison-Wesley, 1995).. Таким образом, ООП позволяет описать задачу в контексте самой задачи, а не в контексте компьютера, на котором будет исполнено решение. Впрочем, связь с компьютером все же сохранилась. Каждый объект похож на маленький компьютер; у него есть состояние и операции, которые он позволяет проводить. Такая аналогия неплохо сочетается с внешним миром, который есть «реальность, данная нам в объектах», имеющих характеристики и поведение.
 
Алан Кей подвел итог и вывел пять основных черт языка Smalltalk — первого удачного объектно-ориентированного языка, одного из предшественников Java. Эти характеристики представляют «чистый», академический подход к объектно-ориентированному программированию:
 
  • Все является объектом. Представляйте себе объект как усовершенствованную переменную; он хранит данные, но вы можете «обращаться с запросами» к объекту, требуя у него выполнить операции над собой. Теоретически абсолютно любой компонент решаемой задачи (собака, здание, услуга и т. п.) может быть представлен в виде объекта.
  • Программа — это группа объектов, указывающих друг другу, что делать, посредством сообщений. Чтобы обратиться с запросом к объекту, вы «посылаете ему сообщение». Более наглядно можно представить сообщение как вызов метода, принадлежащего определенному объекту.
  • Каждый объект имеет собственную «память», состоящую из других объектов. Иными словами, вы создаете новый объект с помощью встраивания в него уже существующих объектов. Таким образом, можно сконструировать сколь угодно сложную программу, скрыв общую сложность за простотой отдельных объектов.
  • У каждого объекта есть тип. В других терминах, каждый объект является экземпляром класса, где «класс» является аналогом слова «тип». Важнейшее отличие классов друг от друга как раз и заключается в ответе на вопрос: «Какие сообщения можно посылать объекту?»
  • Все объекты определенного типа могут получать одинаковые сообщения. Как мы вскоре убедимся, это очень важное обстоятельство. Так как объект типа «круг» также является объектом типа «фигура», справедливо утверждение, что «круг» заведомо способен принимать сообщения для «фигуры». А это значит, что можно писать код для фигур и быть уверенным в том, что он подойдет для всего, что попадает под понятие фигуры. Взаимозаменяемость представляет одно из самых мощных понятий ООП.
 
Буч предложил еще более лаконичное описание объекта:
 
Объект обладает состоянием, поведением и индивидуальностью.
 
Суть сказанного в том, что объект может иметь в своем распоряжении внутренние данные (которые и есть состояние объекта), методы (которые определяют поведение), и каждый объект можно уникальным образом отличить от любого другого объекта — говоря более конкретно, каждый объект обладает уникальным адресом в памяти. Это верно с некоторыми ограничениями, поскольку объекты могут реально существовать на других машинах и в различных адресных пространствах, и также могут храниться на диске. В этих случаях, индивидуальность объекта должна определяться чем-то иным, чем адресом памяти.

Проводим параллели:
Суть второго этап ПФУ (Формирование навыка (стереотипа) распознавания фактора среды на будущее) на практике сводится к выявлению характеристик этого фактора среды, в отношении которого будет разворачиваться управление, и их метрологии. В ООП этот ни что иное как описание Класса.

  • Класс в ООП - это "Объект управления"(фактор среды) в ДОТУ.
  • Переменная класса - Параметр, характеризующий объект управления.
  • Тип переменной класса - метрология параметра.
  • Методы класса - решение задачи устойчивости по предсказуемости.
  • Наследование классов - иерархическая структура параметров.
Понимание принципиальной разницы между понятиями класс и объект в ООП имеет такое же ключевое значение как понимание разницы между параметром фактора среды и значением этого параметра в ДОТУ. В ООП объекты появляются, когда речь заходит о конкретных параметрах. В ДОТУ тоже есть это появление - состояние объекта управления в конкретный момент времени в заданных обстоятельствах. Формулировка довольно растянутая, всё дело в том, что мат.часть ДОТУ не дает направления движения.

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

Закончу пока с параллелями. Думаю, профессиональные программисты могут привести заметно более интересные примеры.
Комментарии (1)
Это гениально, сам пришел абсолютно к тем же выводам.
Я подумал, если бы я был богом, как бы я реализовывал мир:
подход - сделать матрицу материи - в основном пустую, а потом заполнять ее элементами объектов/или самими объектами, да еще и рассчитывать законы по которым они могут перемещаться. крайне контрпродуктивен и затратен с точки зрения вычислений!
а тут объект - Материя, он обладает Информацией о себе сам - свойства объекта, и к нему можно применять ограниченный спектр методов, которые по определенным правилам меняют свойства этого и других объектов - вот вам и МЕРА - просто - и всеобъемлюще.
Каждый объект наделяем мерой и информацией и они сами играют в игру - ЖИЗНЬ!
более того, достаточно сформировать базовые элементарные частицы и заложить основы взаимодействия - после чего они сами будут составлять макрообъекты.
Добавить комментарий

Новые комментарии