Заметила, что в последнее время в объявлениях о работе много где требуют, чтобы кандидат был хотя бы знаком с концепциями ABAP Objects и ОО. Но с кем бы из ABAPеров я не говорила, реакция обычно примерно такая:
- О, ABAP Objects - это сила!
- А где вы их применяете?
- Хм... Да, в сущности, нигде...

Я с ABAP работаю уже 5 лет, об ОО представление имею постольку-поскольку (изучала немного Java и C# чисто из интереса). Как я понимаю, основными преимуществами там являются multi-threading и inheritance. Но, применительно к системам, где я работала, честно говоря, ни разу не видела необходимости писать какие-то свои классы, методы и т.п.

Да, я запросто могу создать объект и вызвать стандартный метод какой-нибудь (ALV - типичный пример), но это IMHO не какое-то офигенное достижение и требует познаний достаточных разве что для того, чтобы не пытаться вытащить private переменную, как тут в одном топике.

Коллеги Objects тоже не интересуются совершенно. Это только у нас контора такая отсталая? Может мы что-то упускаем?

ALV GRID, Enhansments, BADI ну и в случае "подлома" чего-нибудь стандартного изначально объектного.

Вот если бы была возможность, например, заказ в ММ "наследовать" из заявки, тогда объектность была бы во всей красе.
Но стандарт уже написан на процедурах, посему и объектность можно пока применять только в интерфейсах пользователя.
BAPI, теоретически как-то на объектно-рожденные похожи, но реально не видел применения.

http://sapdocs.info/wp-content/uploads/ ... bjects.pdf

Подробней некуда и с примерами. Правда сам я тоже ООПом особо не пользуюсь (только чужими классами).

Впринципе, согласен, что круг задач в SAP достаточно беден. Поэтому повсеместное применение ООП не всегда изящно, и иногда даже слишком громоздко. Но есть, например, модуль RE, где без знания ООП трудно.

Для RE-FX пришлось много делать через BADi, там все на ООП, но это использование саповских объектов, свои еще ни разу не создавала

Пардон конечно, но что такое BADI? Реализация интерфейса своим классом

Самый простой пример. Есть транзакция с 5ю и более таблицами в виде ALV. Принцип их ведения почти одинаковый - отличаются только набором полей, и еще какими-то "фичами". Создается родительский класс, который создает объект ALV Grid, генерит каталог полей, изменяет панель кнопок, обрабатывает изменения, регистрирует события, и т.д. А в наследниках, если необходимо, переопределяются только нужные методы: каталог полей, например. В результате объем кода существенно уменьшается. Это если с умом подходить.

Пример 2. Все GOS объекты расширяются именно через классы.

P.S. Structure of a Business Object Type

Достаточно посмотреть как реализованы транзакции в последних "изданиях" системы (для FI, MM, HR, ...)- они построены на классах, в BADI для доступа к данным всё больше и больше используется ООП (классы, интерфейсы, исключительные ситуации).
ALV разных мастей. А ALV это значительный объём в разработках.
Так что "нигде" сильно приуменьшено, ABAP Object хоть медленно, но верно входит в жинь.

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

Я использовал ОО для преобразования собственной функциональной группы в объекты, т.к. необходимо было разделить значения глобальных переменных в пределах одной программы.

E-Recruiting - весь framework построен на ООП.

SRM 7.0 - WebDynpro - класс на классе и классом погоняет. Все документы (корзинка, заказ и т.п.) представлены классами.
Для создания своих расширений, например для POWL используется наследование стандартных классов - очень удобно.

Программирование без ОПП - это скучно. Для более-менее серьезных программ обязательно использую классы. Тут уже упоминали статью про 8 причин использования классов. Я для себя выделил следующие:
1) Реализация принципа "разделения обязанностей". В больших программах всегда много глобальных переменных и подпрогамм, в которых очень сложно ориентироваться. Группировка логически связанных данных и операций над ними в отдельные классы позволяет уменьшить сложность программы.
2) Часто в программах встречается сложная логика условных операторов (встречал и 5, и 6 вложенных IF). Тут все можно заменить "полиморфизмом". Что, опять же, позволяет уменьшить сложность прогаммы
3) Использование "функциональных методов", т.е. возвращающих одно значение. Очень удобно, так как их можно использовать в некоторых операторах, в частности, в логических выражениях.

В небольших программах использование классов не оправдано, так как разделение описания интерфейса и его реализации приводит к необходимости написания дополнительного кода, который ничего не делает. Но, к счастью, были у меня и другие программы, где пришлось изголяться по полной, используя шаблоны проектирования. А какая красота получилась!
Естественно, любую программу можно написать, используя функциональный подход. Другой вопрос, ценой каких усилий. И сможет ли ее сопровождать кто-то, кроме автора.

Спасибо всем за ответы. Думаю в преимуществах ООП никто не сомневается, меня интересовала чисто практическая сторона дела. Просто на недавнем интервью товарищ спросил, какой у меня опыт с Objects и после того, как я упомянула ALV, BADI и прочая, он с гонором переспросил: "Ну а свои-то классы вы писали?". Своих классов я пока в SAP не писала, но это не потому, что я тупая или не умею - просто не было нужды. Как уже правильно заметили выше - если это делает программу более громоздкой, то зачем? В общем для меня такой вопрос был скорее похож на примитивную распальцовку.

Кстати, интересно, что авторы приведенной выше статьи про 8 причин начинают с того, что подозревают в косности почему-то именно программистов. Хотя, например, в нашей SAP системе, которой уже лет 20, мне с большим скрипом удалось всего несколько совершенно жутких отчетов хотя бы на ALV перевести. Пришлось делать прототип, собирать ключевых юзеров, терпеливо объяснять им преимущества и т.п. И то многие просто упираются ногами и руками - не дай бог как-то изменить их любимый отчет. (В принципе их тоже понять можно, конечно.)

В общем я понимаю вашего интервьюера, действительно между написанием собственных объектных программ и использованием готовых классов огромная разница. Откровенно говоря, я и сам задавал такой вопрос лет 12-15 назад на собеседованиях. Просто с момента, когда появились системы типа Delphi с кучей готовых компонент, одновременно объявилось много людей, называющих себя программистами. А на деле они только и умели использовать готовые компоненты, не понимая даже сути объектного программирования.
Так что вопрос действительно хороший, чтобы, в некоторой степени, оценить уровень программиста!

Но!!! Что касается SAP, есть другая сторона вопроса. Поскольку ООП оправдано при написании довольно больших собственных разработок, возникает сомнение в правильности этих проектных решений вообще. Таки при внедрении R/3 надо и внедрять R/3 (простите за тафтологию), а не кустарщину, которую потом неизвестно кто и как будет поддерживать.
В общем это отдельная тема, но наводит на размышления, стоит ли рассматривать большой опыт ООП в SAP, как положительный?!

Тут надо оговориться - опыт использования и знание основ ООП все-таки разные вещи... Увы именно в SAP часто сталкиваюсь со "случайными" людьми в программировании.
У меня даже полушуточная классификация плохих программистов появилась:
Плохой программист 1 рода - ему недостает, скажем так, сообразительности.
Плохой программист 2 рода - нет базовых знаний. Если любознательный, изобретает велосипеды, если нет - пишет как индус.
Плохой программист 3 рода - самый досадный случай - мозг есть, знания есть, но он ими не пользуется.


P.S. Преподаватель по мат.анализу любил говорить, что есть много вещей, которые не применяются в сельском хозяйстве(например про использование несобственных интегралов)