Концепции программирования
Компонентное программирование
Оберон нацелен на компонентно-ориентированную разработку программного обеспечения.[4] Инкапсуляция поддерживается исключительно на уровне модуля — все типы, объявленные внутри модуля, друг для друга абсолютно прозрачны. Из других модулей доступно то, что объявлено при определении как экспортируемое.
Полиморфизм обеспечивается за счёт механизма методов (и процедурные поля в Обероне, и методы в Обероне-2 ведут себя как виртуальные, в терминологии большинства гибридных объектно-ориентированных языков), а также расширенной конструкцией WITH, позволяющей выполнять различные группы операторов в зависимости от того, к какому из расширенных типов относится её аргумент.
В языке отсутствует специальный механизм конструкторов. Рекомендуемым методом создания и инициализации объектов является описание порождающих модулей и процедур (в традиционной терминологии ООП — factory).
Программа в такой технологии представляет собой набор относительно самостоятельных компонентов (в данном случае — модулей), имеющих скрытую от внешнего мира внутреннюю структуру и чётко определённый интерфейс. Модули могут загружаться и выгружаться динамически, во время работы программы, система предоставляет развитые средства контроля типов во время выполнения, которые позволяют писать универсальные алгоритмы обработки данных, не зависящие от конкретных типов этих данных (например, библиотека для работы с СУБД может предоставлять методы, записывающие результат запроса из базы в запись произвольной структуры, если набор и типы полей этой записи соответствуют набору и типам полей в БД).
В компонентной парадигме считается неудачным архитектурное решение, связанное с широким использованием наследования реализации от типов, объявленных в другом компоненте, поскольку это приводит к явлению, известному как «хрупкость базового типа» — после того, как от базового типа порождено большое количество типов-наследников (причём часть из них может быть даже неизвестна разработчику базового типа), любые изменения в реализации базового типа становятся крайне рискованными, так как они могут непредсказуемым образом отразиться на типах-потомках.
Известно, что одной из проблем применения объектно-ориентированного программирования в системном программировании является необходимость иметь группы маленьких классов, которые могли бы взаимодействовать без дополнительных накладных расходов. В Обероне этой проблемы нет — все типы, определённые в одном модуле, видят друг друга, а проблем с надёжностью это не создаёт, так как модуль всё равно разрабатывается, тестируется и сопровождается как единое целое.
Типичная система, разработанная на Обероне, представляет собой набор модулей с процедурными интерфейсами, через которые модули обмениваются данными, в том числе и объектами. При этом все средства инкапсуляции действуют только в межмодульном взаимодействии, что делает удобным системное программирование с использованием объектов.
Объектно-ориентированное программирование
Средства объектного программирования интерпретируются в Обероне как естественное развитие средств работы с записями в модульной системе, точнее, как технический инструментарий для решения конкретной архитектурной задачи: обеспечить эффективное «разделение труда» между различными модулями при работе с динамическими типами и структурами данных: например, работа с указателями в списке может быть скрыта (вместе с соответствующими полями) в одном модуле, а определение и работа с конкретным «наполнением» элементов списка — задаваться в другом (или, чаще, других). В этом смысле технология объектного программирования в Обероне подчинена концепции модульности: она здесь является, скорее, средством описания данных, чем средством построения архитектуры приложения в целом.