Вот! Именно поэтому у меня и вызвала удивление такая буквально одержимость объектами. Если уж дошло до создания своих классов, то невольно задумываешься, а зачем, собственно, это делать в R/3...

Создание собственных классов наследованием от стандартных работает как расширение функциональности. Посмотрите, например, в сторону POWL.

Здесь немного про попытку применения OO в SAP:
http://sapboard.ru/forum/viewtopic.php?f=18&t=1462&start=15

Например, мне нужно было распарсить XSD-шаблон, а как структуру документа хранить в программе? Конечно, объектно. Получилась красивая объектная обертка. Был класс "узел xml", "узел-таблица", "строка таблицы" итд. Наследовались они от абстрактного базового класса, что-то переопределялось, что-то добавлялось. В абстр. классе, например, можно определить все атрибуты, которые есть у всех объектов (имя xml-тэга, например).

Также была задачка построить иерархический отчет. Узлы и Листочки отчета - инстанции классов. Листы умеют выбирать нужные данные, а узлы должны считать суммы всех подчиненных узлов и листов. В итоге подсчет всего запускается одним лишь вызовом: - рекурсивный обход иерархии. Узлы и листы наследуются от абстрактного класса, в котором есть метод calculate. В каждом классе метод соответсвенно переопределяется. Очень удобно.

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

Не спорю, что это всё можно было сделать и с помощью функционального подхода, но это неудобно.

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

Участвовал в разработке... можно назвать ее маленьким Z-модулем.
Приняли волевое решение писать на классах, что в итоге и сделали.
В целом понравилось, например такие удобные вещи (уже упоминали):

или такая работа с глобальными константами


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

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

как я вас понимаю!
примерно та же история.

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

Классы в ABAP'е удобны хотя бы тем, что у них статическая проверка типов, а у ФМников - динамическая (т.е. типы проверяются только в момент запуска).
Начиная с ABAP 7.4 очень удобно объявлять выходные переменные прямо при вызове метода (inline declaration), чего с ФМом сделать никак нельзя.

Дополню, т.к. с тех пор "много воды утекло".
Последние лет 5 активно использую классы, причём глобальные. Опять же, об общих преимуществах ООП писать не буду, а затрону лишь специфику его использования в SAP.

Очень удобны глобальные классы при коллективной разработке большого проекта:
- Хотя бы уже тем, что можно редактировать отдельные методы одного класса, не блокируя друг друга. Не раз сталкивался с проблемой блокирования какого-нибудь инклуда при необходимости изменения подпрограммы, даже в рамках поддержки, а не больших разработок.
- Интерфейс ведения глобального класса улучшает навигацию по его отдельным частям и позволяет создавать их краткие описания и документацию, что полезно само по себе (для себя любимого) и очень выручает в создании документации описания разработок при сдаче проекта, особенно если этот процесс автоматизировать.
- Упрощает использование глобального пространства имён, сокращает риски их пересечения, особенно при повторном использовании ABAP-кода на разных проектах. Например, вы вынуждены придумывать уникальные имена ФМ-ов, не смотря на то, что они в разных функциональных группах. С методами такой проблемы нет, достаточно один раз придумать имя глобального класса. По этой же причине часто можно обойтись публичными типами и атрибутами вместо словаря.
- Параметры методов, в отличие от параметров подпрограмм, могут быть необязательными, иметь значения по умолчанию, более чётко разделены по виду доступа (Importing, Exporting, Changing, Returning). Это заметно облегчает доработку методов, без необходимости изменения всех существующих вызовов. В общем имеют все преимущества ФМ-ов, но исключают их недостатки.
- Довольно просто преобразуются в локальные классы, что позволяет компоновать легко (Copy/Past) переносимые утилиты. Например, моя утилита ZWWW_MIGRATE из разработки ZWWW версии 3.05 теперь полностью перенесена на классы и содержит их несколько десятков, что позволяет мне иметь все описанные преимущества разработки. Однако, для использования на других системах, я компоную её (автоматически) в один простой Report. Думаю, этот приём также можно использовать для создания демо-версий программ, ограничивая их функциональность (недокладывая некоторые объекты), а также не замусоривая систему потенциального клиента кучей ненужных (пока) объектов.
- Позволяет создавать не только повторно используемые функции (используя наследование), но и повторно используемые программы (с экранами, экранной логикой и т.д.). Что позволяет дорабатывать свои универсальные решения без их ломки под специфику конкретного клиента.

Например, так выглядит отчёт:


А так выглядит наследованный отчёт, дополняющий и переопределяющий функциональность предыдущего:


p.s.
Если ещё чего вспомню, допишу позже...