Кто-нибудь пользуется OOP при создании структуры IDOC, или все делают по старинке, как в SAP стандарте?

Что скажете, если вместо:

ls_edidd-segnam = 'E1EDK01'.
ls_edidd-sdata = ls_e1edk01.
APPEND ls_edidd TO lt_edidd.

Использовать:

CALL METHOD ycl_idoc=>e1edk01
EXPORTING
iv_action = 'A'
is_e1edk01 = ls_e1edk01
CHANGING
ct_edidd = lt_edidd[].

И так для каждого сегмента.

Для меня лично большой плюс в том, чтобы можно было через where-used посмотреть,
где именно был данный сегмент изменен. Особенно важно если человек 15 работает,
и время от времени с IDOC-ами непонятно что происходит.

Статика, фу... Еще один вариант, наравне с формами и макросами... Это не OOP...

что для Вас ООП?
исключительно создание инстанций?
Создал инстанцию - молодец, владеешь навыками ООП.

Коллеги, может прочитаете вопрос внимательнее?

Он состоит из двух частей:

1. Использует ли кто OOP при создании структуры IDOC
2. Пример (базовый, который и OOP то назвать нельзя)

Отвечайте пожалуйста по существу и не флудите.

Про это много умных книжек написано.

Мы здесь обсуждаем OOP как таковой, а его применение к SAP IDOC.

Вы на мой вопрос не ответили.

А я и не отвечал на Ваш вопрос, потому что не вижу в нем смысла.
Я задал свой Константину, цитату забыл оформить

А что можно ответить на Ваш вопрос?
Вы когда программу нпишите тоже спрашиваете, оформлять ли Вам кусок кода в perform или так оставить?
В чем суть? Ну нравится Вам класс попользовать, ну попользуйте. хотите ФМ - сделайте ФМ или include впишите.
Ясно, что удобнее.

Много умных книжек - хорошо. Надо читать.

Можно было ответить:
a.) Да, использую OOP при создании структуры IDOC
b.) Нет, не использую OOP при создании структуры IDOC
c.) Другое

Просто хочу понять - в других больших командах все пишут код как хотят, или все-таки используется единый стандарт? Если при заполнении структуры IDOC одни будут использовать perform, другие ФМ или include, нехорошо получится.

Вот я и спрашиваю, как другие решают данный вопрос, хотя бы на уровне элементарных ФМ, статики, и т.д.

Есть теперь смысл в моем вопросе?

У больших командах, как и у маленьких, и у средних должен(может) быть регламент разработок. Где прописываются всякие разные моменты, относящиеся к разработкам. Если есть идея использовать какой-то ФМ или класс - эта идея доводится до руководителя разработки, который и принимает решение( возможно просле коллективного совещания), доводит до сведения, заносит в регламент, отслеживает и карает.

Спасибо, уже ближе Регламент разработки IDOC это и есть то, что я пытаюсь создать, просто думаю, стоит ли оно того.

Итак, сформулирую свой вопрос с употреблением умных слов.

Lars, лично в Вашей команде:
1. Есть ли регламент разработок?
2. Если регламент есть, то упомянуто ли там что-либо насчет разработок IDOC?

(ответ да-нет)

Какой Вы строгий, насяльника. С Вами прям не забалуешь.

1. да
2. нет

Lars, спасибо

Константин, вместо того чтобы флудить, заполните опросник:

В Вашей команде:
1. Есть ли регламент разработок?
2. Если регламент есть, то упомянуто ли там что-либо насчет разработок IDOC?

(ответ да-нет)

1. Да
2. Нет

Регламенты составляются на все разработки, а не конкретно на IDOC...

@Lars: OOP - это абстрагирование, наследование, полиморфизм, инкапсуляция + разумное применение всего этого. Использование классов как оберток для кода возможно, но с ООП не имеет ничего общего. Поэтому тема топика не соответствует вопросу о том, какие концепции использутся в проектах при разработке IDOCs. По сути вопрос о том, стоит ли использовать модульное программирование (разбиение на модули, будь то статические методы, функции, формы или макросы) или нет.

А по тому коду, который приведен ваше, можно сделать выводы о том, что не используется наследование, например?
Или что приведенный метод внутри не использует концепцию полиморфизма и инкапсуляции?
Тоесть Вы считаете, что вызов статического метода экземпляра класса - это не ООП, или
статический метод и атрибуты - это только чтобы обертку сделать?

Тема для холивара, предлагаю не развивать, так как, в принципе, согласен

Согласен, вопрос поставил не совсем четко. Я действительно имел ввиду не абстрагирование, наследование, полиморфизм, инкапсуляция + разумное применение как таковые, а скорее концепции разработки IDOC, и OOP как высшую их форму