Привет коллеги! В предыдущем статья Мы говорили о проблеме общего ядерного оружия в целом, в этой статье мне хотелось бы развить эту тему и показать более конкретно проблемы общего ядерного оружия.
Ключевые идеи : У ООЛП есть две ключевые проблемы: неполная объектная парадигма и преждевременная типизация.
Неполная объектная парадигма не определяет концепцию композиции нетипизированных объектов (композиция — наиболее важный элемент любой парадигмы).
Преждевременная типизация ограничивает семантику абстрактных понятий (семантических абстракций).
Неполная объектная парадигма
Объектная парадигма не определяет явно лежащие в ее основе механизмы.Любая парадигма должна определять:
- Примитив абстракции – определяет стиль мышления парадигмы и является базовым элементом моделирования.
- Композиция примитивов – позволяет описывать (моделировать) системы произвольной сложности.
Сама композиция также должна быть примитивной.
- Отношение агрегации – абстрактный механизм, соединяющий примитивы в композиции.
Точно такой же механизм проявляется у примитива во внешнем взаимодействии.
- Глобальное состояние – где (но не как!) будет локализовано абстрактное (наблюдаемое) состояние системы.
Это свойство является не столько парадигмой, сколько следствием вычислительной архитектуры.
Результат выполнения любой модели можно обнаружить только по изменению состояния в самом общем смысле.
Чтобы использовать парадигму (не путать с использованием языка, основанного на этой парадигме), набор текста не нужен.
Парадигма должна лишь определять, как и на каких механизмах построена модель (т.е.
одна или несколько композиций).
Что еще более важно, композиция, а не примитив, является строительным блоком моделирования из-за сложности моделируемых систем.
Композиции — это чистые смысловые абстракции.
, без привязки типа или каких-либо других «ресурсов».
Семантическая абстракция — это понятие, определяемое только своим именем, а также именем в любой форме, словом или фразой.
Например, этим свойствам полностью удовлетворяет функциональная парадигма (то же самое можно показать и для процедурно-императивной парадигмы):
- Примитив абстракции: функция – отображает некоторый вход на некоторый выход.
- Функциональная композиция: цепочка функций (отображений).
- Отношение агрегации: выходные данные одной функции подаются на вход другой.
Те.
это соединение в композиции и сам вызов функции.
- Глобальное состояние: аргументы функции.
Все является объектом.
Объекты взаимодействуют друг с другом.
– здесь как минимум подразумевается состав объекта, и его можно как-то логически вывести.
Конечно, технически в ООЛП можно увидеть композиции в том или ином виде, но композиция объектов должна быть основным и основным механизмом OOLP, а не дополнительным и второстепенным.
.
Как примерно должна выглядеть объектная парадигма (по аналогии с функциональной):
- Примитив абстракции: объект — это агент, поддерживающий некоторый протокол взаимодействия.
Протокол подразумевает правила и семантику взаимодействия для обеих сторон.
- Состав объектов: граф объектов, поддерживающих протоколы друг друга.
Сам граф является объектом со своим протоколом.
- Отношения агрегации: поддержка протокола объекта (т. е.
понимание и следование протоколу).
Возможность поддержки протокола друг друга связывает объекты в композицию, так же как внешнее взаимодействие с конкретным объектом возможно только при поддержке его протокола.
- Глобальное состояние: внутреннее состояние объекта.
изменяющим состояние) примитивом.
.
Поскольку глобальное состояние распределяется между объектами (в OOLP это инкапсуляция), протокол объекта становится способом изменения состояния.
Это должно быть отражено на уровне объектной парадигмы.
Для этого объектная парадигма может использовать любую парадигму с преобразующим примитивом, собственно функциональные и/или процедурные парадигмы объектных протоколов.
Обе парадигмы используются в одной и той же абстрактной, нетипизированной форме.
Если протокол объекта основан на функциональной парадигме, мы получаем неизменяемый объект, а если он основан на процедурной парадигме, то мы получаем изменяемый.
Преждевременное набор текста
Типизация (система типов) в конечном итоге нужна для одной цели: формальная проверка правильности программы.Правила задаются через грамматику языка, и переводчик на основе грамматики осуществляет фактическую проверку.
Преждевременность типизации заключается в том, что CLLP (классово-ориентированные) уделяют большое внимание использованию типов, обращению с классами как с типами.
Первое, что бросается в глаза (как на практике при использовании ООЛП, так и в учебниках/книгах при описании ООЛП) — это система типов ООЛП, хотя в теории должна быть объектная парадигма с ее составом и семантическими абстракциями.
Ссылочные типы и типы значений, полиморфизм подтипов, наследование, принцип подстановки Лискова (LSP), перегрузка методов, дженерики, абстрактные типы данных, функциональный тип и FVP как элементы функционального программирования, вывод типов, приведение типов, абстрактные классы и интерфейсы — все эти понятия являются следствием типизации.
С одной стороны, типизация неизбежна, поскольку могут выполняться только правильные программы.
Но с другой стороны, появление типизации вносит ограничения на семантику абстракций.
Идея состоит в том, чтобы отложить появление набора текста как можно позже.
Другими словами, формальная проверка правильности должна проводиться только после того, как определен состав объекта .
В идеале типизация должна быть подключаемой, ее место где-то перед этапом компиляции, а проверка собственно выполняется на этапе компиляции.
Если взглянуть на типографию шире, то Преждевременная типизация в ООЛП проявляется также в фиксированной интерпретации абстрактных механизмов объектной парадигмы в виде конкретных типов реализации.
.
Показательным примером является то, что объектный протокол (также известный как контракт) жестко реализуется в виде методов с фиксированной структурой и поведением (параметрами, возвращаемым значением) как один из возможных типов реализации объектного протокола.
Причина добавления модификаторов методов async/wait в C# заключается в том, что, видимо, стало ясно, что жесткая (синхронная) связь между вызовом метода и возвращаемым значением не соответствует практическим задачам.
На самом деле это исправление последствий преждевременного набора текста.
Опять же, в идеале конкретный тип реализации протокола должен быть подключаемым к конкретной реализации любого механизма.
Идея подключаемой типизации мне видится в виде нескольких этапов (это не какой-то водопадный процесс разработки ПО, все этапы происходят при написании кода, не выходя из IDE).
Описана объектная модель (одна/несколько нетипизированных объектных композиций), содержащая только семантические абстракции.
Объекты, их протоколы, композиции объектов — всё неформально описывается в виде семантических абстракций.
На этом этапе смысл объектной модели вытекает из самих концепций.
Тогда это происходит атрибуция, т.е.
определение (привязка) нетипизированных атрибутов для семантических абстракций.
.
Результату приписывают смысловые абстракции.
Атрибуты не являются полями данных, свойствами и т. д. из ООП/OOLP, атрибуты определяют смысловая структура концепции.
На этапе атрибуции вообще отсутствует понятие государства.
Следующий этап - абстрактная (нетипизированная) реализация объектных протоколов (традиционно говоря – реализация методов).
Для объектных протоколов выбирается парадигма реализации с преобразованием примитивов (функциональных и/или процедурных).
На этом этапе атрибуты уже доступны, но они (как и абстрактные функции и/или процедуры) по-прежнему являются семантическими абстракциями.
Использование преобразовательных парадигм на этом этапе подразумевает абстрактное состояние объектов (поскольку есть что трансформировать), а структура этого состояния вытекает именно из атрибутов объектов.
Далее идет конкретная (типизированная) реализация – здесь происходит привязка типов к объектам и их атрибутам, а также параметрам/аргументам в объектных протоколах.
Абстрактные процедуры/функции абстрактной реализации объектных протоколов создаются в традиционных конструкциях, таких как методы класса.
Отдельно отмечу, что привязка типов происходит посредством внедрения выражений, а не путем указания имени типа.
Другими словами, тип выводится из типа выражения, что гарантирует явную инициализацию.
После этапа конкретной реализации все концепции типизируются и может быть проведена формальная проверка (в рамках перевода).
Заключение
Выявленные проблемы, на мой взгляд, являются причиной того, что НЛНП принципиально противоречивы.Неудивительно, что ООП и ООП в их нынешнем виде всегда будут объектом критики.
Есть и третья проблема, но она касается не только OOLP, но и других языков: это синтаксис, основанный на грамматике текста.
В настоящее время поддержка текстовых грамматик в IDE настолько развита, что возникает вопрос: зачем требуется текстовое представление кода? IDE манипулируют целыми строительными блоками, такими как методы или выражения, которые ухудшают сам текст. Сравнивать версии в системах контроля версий в виде текста? Но это всего лишь вопрос реализации поддержки в IDE. Синтаксис, основанный на текстовой грамматике, ограничивает мета-возможности по той же причине, по которой мета-уровень требует дополнительной поддержки со стороны IDE, и нет смысла указывать их как текст. Те.
метафункции реализованы только на уровне IDE. По сути, IDE — это грамматика.
Поэтому глобальная идея заключается в разработке объектно-ориентированного языка (т.е.
IDE) на основе четкой объектной парадигмы, без текстовой грамматики и с развитыми мета-возможностями преобразования объектных композиций в читаемый код. Теги: #ООП #языки программирования #программирование #ООП
-
Установка Red5 На Debian
19 Oct, 24 -
Лампа Настроения
19 Oct, 24 -
Защита Пользовательских Данных
19 Oct, 24 -
Разделить Значит Умножить
19 Oct, 24
