| Предыдущая версия справа и слева
Предыдущая версия
|
|
ob:docu [2024/02/21 18:08]
comdiv [Языки семейства Оберон] |
ob:docu [2025/07/11 23:32] (текущий)
efimov |
| |
| |
| ==== Оберон [Oberon] ==== | ==== Оберон ==== |
| |
| Проект Оберон был начат в 1985 в ETH Виртом и его коллегой Юргом Гуткнехтом [Jurg Gutknecht]. Это была попытка выделить все существенное из системы Cedar в виде универсальной, но все же обозримой операционной системы для рабочих станций. Получившаяся система оказалась очень маленькой и эффективной, прекрасно работала в оперативной памяти размером всего 2 MB и требовала при этом лишь 10 MB памяти на диске. Важной причиной малого размера системы Оберон был ее компонентный дизайн: вместо интеграции всех желаемых средств в один монолитный программный колосс, менее часто используемые программные компоненты (модули) могли быть реализованы как расширение ядра системы. Такие компоненты загружались, только когда они были действительно нужны, и они могли совместно использоваться всеми приложениями. | |
| |
| Вирт понял, что компонентно-ориентированное программирование требовало некоторых средств объектно-ориентированного программирования, таких как упрятывание информации [information hiding], позднее связывание [late binding] и полиморфизм. | Проект Оберон был начат в 1985 году в Швейцарской высшей технической школе Цюриха (ETH Zurich) Николаем Вальтеровичем Виртом (Niklaus Wirth) и его коллегой Юргом Гуткнехтом. Цель проекта заключалась в выделении всего наиболее существенного из системы Cedar и создание универсальной, но при этом компактной операционной системы для рабочих станций. Результатом стала чрезвычайно маленькая и эффективная система, которая могла полноценно работать в оперативной памяти объёмом всего 2 Мбайта и требовала лишь 10 Мбайт дискового пространства. Одной из ключевых причин её компактности был компонентный подход к проектированию: вместо включения всех возможных средств в один монолитный программный колосс, менее часто используемые функциональные возможности реализовывались в виде отдельных модулей-расширений. Такие компоненты загружались только по мере необходимости и могли совместно использоваться разными приложениями. |
| |
| Упрятывание информации было сильной чертой Модулы-2. Позднее связывание поддерживалось в Модуле-2 посредством процедурных переменных. Однако там не было полиморфизма. Поэтому Вирт добавил расширенное переопределение типов [type extension]: записевый тип мог быть объявлен как расширение <потомок> другого записевого типа <предка>. Тип-потомок можно было использовать всюду вместо одного из его предков. | Вирт понял, что компонентно-ориентированное программирование требовало некоторых средств объектно-ориентированного программирования, таких как сокрытие (information hiding), позднее связывание и полиморфизм. |
| |
| Но компонентно-ориентированное программирование выходит за рамки объектно-ориентированного. В системе, построенной из компонентов, компонент может разделять свои структуры данных с произвольным числом других компонентов, о которых она ничего не знает. Эти компоненты обычно также не знают о существовании друг друга. Такое взаимное незнание делает управление динамическими структурами данных, и в частности правильное освобождение уже ненужной памяти, принципиально более трудной проблемой, чем в закрытых программных системах. Следовательно, необходимо оставить на долю реализации языка всю работу по определению момента, когда какая-то область памяти более не нужна, чтобы повторно использовать ее без ущерба для безопасности системы. Системный сервис, выполняющий такую автоматическую утилизацию памяти, называется сборщик мусора [garbage collector]. Сбор мусора предотвращает две из числа наиболее труднонаходимых и попросту опасных ошибок в программах: утечки памяти [memory leaks] (когда более не используемая память не освобождается) и висячие ссылки [dangling pointers] (преждевременное освобождение памяти). Висячие ссылки позволяют одному компоненту разрушить структуры данных, принадлежащие другим. Такое нарушение защиты типов [type safety] должно быть предотвращено, т.к. компонентные системы могут содержать многие независимо написанные компоненты неизвестного качества (например, полученные из Интернета). | Сокрытие — одна из сильных сторон Модулы-2. Позднее связывание поддерживалось в Модуле-2 с помощью процедурных переменных. Однако в языке отсутствовал полиморфизм. Поэтому Вирт добавил расширение типов (type extension): записной тип (record type) можно было объявить как расширение другого записного типа. Значение такого расширенного типа можно использовать везде, где ожидается значение базового типа. |
| |
| Хотя алголоподобные языки всегда имели высокую репутацию в плане безопасности, введение полной защиты типов (и, следовательно, сбора мусора) явилось качественным скачком. Именно по этой причине полная совместимость с Модулой-2 оказалась невозможной. Получившаяся модификация Модулы-2 была названа как и вся система — Оберон. | Однако компонентно-ориентированное программирование выходит за рамки объектно-ориентированного. В системе, построенной из компонентов, компонент может разделять свои структуры данных с произвольным числом других компонентов, о которых он ничего не знает. Эти компоненты обычно также не знают о существовании друг друга. Такое взаимное незнание делает управление динамическими структурами данных — и в частности правильное освобождение памяти — принципиально более трудной проблемой, чем в закрытых программных системах. Следовательно, необходимо оставить на долю реализации языка всю работу по определению момента, когда та или иная область памяти более не используется, чтобы повторно использовать её без ущерба для безопасности системы. Системная служба, выполняющая такую автоматическую утилизацию памяти, называется мусорщиком (garbage collector). Сбор мусора предотвращает две из числа наиболее труднонаходимых и попросту опасных ошибок в программах: утечки памяти (когда память, которую более невозможно использовать, не освобождается) и висячие ссылки (преждевременное освобождение памяти). Висячие ссылки позволяют одному компоненту разрушить или повредить структуры данных, принадлежащие другим. Такое нарушение защиты типов должно быть предотвращено, т. к. компонентные системы могут содержать многие независимо написанные компоненты неизвестного качества (например, полученные из интернета). |
| |
| Система модулей в Обероне, как и в Модуле-2, обеспечивала упрятывание информации для целых семейств типов, а не только для отдельных объектов. Это позволило определять и гарантировать инварианты для нескольких взаимодействующих объектов. Другими словами, разработчики получили возможность разрабатывать механизмы защиты более высокого уровня, отталкиваясь от базовых средств защиты на уровне модулей и защиты типов, обеспечиваемых хорошей реализацией Оберона. | Хотя алголоподобные языки всегда имели высокую репутацию в смысле безопасности, введение полной защиты типов (и, следовательно, сбора мусора) явилось качественным скачком. Именно по этой причине полная совместимость с Модулой-2 оказалась невозможной. Получившаяся модификация Модулы-2, как и вся система, была названа Обероном. |
| |
| Ортодоксальные объектно-ориентированные языка типа Smalltalk пренебрегали как типизацией переменных (вообще не поддерживая типы), так и упрятыванием информации (ограничивая ее объектами и классами), что явилось большим шагом назад в технологии разработки программного обеспечения. Оберон примирил миры объектно-ориентированного и модульного программирования. | Система модулей в Обероне, как и в Модуле-2, позволяет скрывать не только отдельные объекты, но и целые семейства типов. Это позволяет гарантировать инварианты для группы взаимосвязанных объектов. Иными словами, разработчики получили возможность создавать механизмы защиты более высокого уровня. |
| |
| Последнее требование компонентно-ориентированного программирования — возможность динамически загружать новые компоненты. В Обероне единица загрузки та же, что и единица компиляции — модуль. | Ортодоксальные объектно-ориентированные языки, такие как Smalltalk, пренебрегали как типизацией переменных (вообще не поддерживая типы), так и сокрытием (ограничивая его объектами и классами), что явилось большим шагом назад в технологии разработки программного обеспечения. Оберон примирил миры объектно-ориентированного и модульного программирования. |
| | |
| | Последним требованием компонентно-ориентированного программирования является возможность динамической загрузки новых компонентов. В Обероне единица загрузки совпадает с единицей компиляции — модулем. |
| |
| |
| |
| |
| В 1992 г. сотрудничество с профессором Х.П. Мёссенбёком (H.P. Mossenbock) привело к нескольким добавлениям к первоначальному языку Оберон («Оберон-2»). Так возник фактический стандарт языка. | В 1992 г. сотрудничество с профессором Х. П. Мёссенбёком (H. P. Mossenbock) привело к нескольким добавлениям к первоначальному языку Оберон («Оберон-2»). Так возник фактический стандарт языка. |
| |
| В 1997 г. компания Oberon microsystems, Inc., отделившаяся от ETH (с Виртом в составе совета директоров), сделала некоторые небольшие добавления к Оберону-2 и назвала его Компонентный Паскаль, чтобы четче выразить как его нацеленность (компонентно-ориентированное программирование), так и его происхождение (Паскаль). Это промышленная версия Оберона, являющаяся наследницей первоначального Паскаля и Модулы-2. | В 1997 г. компания Oberon microsystems, Inc., отделившаяся от ETH (с Виртом в составе совета директоров), сделала некоторые небольшие добавления к Оберону-2 и назвала его Компонентный Паскаль, чтобы четче выразить как его нацеленность (компонентно-ориентированное программирование), так и его происхождение (Паскаль). Это промышленная версия Оберона, являющаяся наследницей первоначального Паскаля и Модулы-2. |
