OOP при создании структуры IDOC

Konstantin Anikeev

Lars написал:

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

Объясню чем я руководствовался...

Code:

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

1. Класс вызывает специальный метод для определеннго сегмента. В ООП скорее класс был бы унаследован от общего класса обработки IDOCs и вызывал бы "безликий" (не содержащий имени сегмента) метод общего интерфейса.
2. Статический метод изменяет локальную табличку - очень похоже на обертку. Иначе табличка была бы аттрибутом класса и не нуждалась бы в передаче параметром
3. В ООП я бы ожидал чего-то такого (на основании 1 и 2).

Code:

  ycl_e1edk01->append_seg( ls_e1edk01 ).
........
  lt_edidd = ycl_e1edk01->ycl_e1edk01.

P.S. это всего лишь мои предположения, идею неразвития holy war поддерживаю и умолкаю... Просто счел уместным написать, по каким признакам мне почудилось именно то, что я написал выше...

Maxus

Konstantin Anikeev написал:

Lars написал:

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

Объясню чем я руководствовался...

Code:

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

1. Класс вызывает специальный метод для определеннго сегмента. В ООП скорее класс был бы унаследован от общего класса обработки IDOCs и вызывал бы "безликий" (не содержащий имени сегмента) метод общего интерфейса.
2. Статический метод изменяет локальную табличку - очень похоже на обертку. Иначе табличка была бы аттрибутом класса и не нуждалась бы в передаче параметром
3. В ООП я бы ожидал чего-то такого (на основании 1 и 2).

Code:

  ycl_e1edk01->append_seg( ls_e1edk01 ).
........
  lt_edidd = ycl_e1edk01->ycl_e1edk01.

P.S. это всего лишь мои предположения, идею неразвития holy war поддерживаю и умолкаю... Просто счел уместным написать, по каким признакам мне почудилось именно то, что я написал выше...

Подход Константина, похоже самый оптимальный.

Только у меня у самого появились сомнения насчет моей идеи:
стоит ли городить столько классов сколько есть сегментов в IDOC,
только ради возможности поиска...

Цитата:

Structure Name
ORDERS05 Purchasing/Sales

Header

E1EDK01 IDoc: Document header general data
E1EDK14 IDoc: Document Header Organizational Data
E1EDK04 IDoc: Document header taxes
E1EDKA3 IDoc: Document Header Partner Information Additional Data

E1EDK02 IDoc: Document header reference data
E1EDK17 IDoc: Document Header Terms of Delivery
E1EDK18 IDoc: Document Header Terms of Payment
E1EDKT1 IDoc: Document Header Text Identification
E1EDKT2 IDoc: Document Header Texts

Rows ( Items )

E1EDP01 IDoc: Document Item General Data
E1EDP02 IDoc: Document Item Reference Data
E1CUREF CU: Reference order item / instance in configuration
E1ADDI1 IDoc: Additionals
E1EDP03 IDoc: Document Item Date Segment
E1EDP04 IDoc: Document Item Taxes
E1EDP05 IDoc: Document Item Conditions

(И это только малая часть...)

Jelena

Maxus написал:

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

Честно говоря, не совсем понятна суть конкретной проблемы.

А зачем вообще что-то изменять в стандартных сегментах? Пускай себе будут как есть. Если что-то надо свое, так расширяйте IDoc. Если же программа просто создает IDoc и заполняет сегменты данными, то по идее такая программа должна быть одна и ее должно быть нетрудно отловить. Ну а кто в программе покопался - это уж вообще проще простого установить.

По-любому должны быть стандарты development и документация. Правда заставить все 15 человек следовать стандартам и писать документацию - это уже отдельная проблема. Тут вон дай бог каждого принудить хоть тексты сообщений не писать прямо в коде. :roll:

Maxus

Jelena написала:

Честно говоря, не совсем понятна суть конкретной проблемы.

А зачем вообще что-то изменять в стандартных сегментах? Пускай себе будут как есть.

Так уж получилось, что до меня был выбран путь менять-добавлять-удалять стандартные сегменты.
Теперь приходится со всем этим справляться.

Jelena написала:

Если что-то надо свое, так расширяйте IDoc. Если же программа просто создает IDoc и заполняет сегменты данными, то по идее такая программа должна быть одна и ее должно быть нетрудно отловить. Ну а кто в программе покопался - это уж вообще проще простого установить.

Есть куча юзер-экзитов и функций, классов, где все это происходит. Тем более, на отдельный класс изменения сегмента E1EDK01 можно поставить break-point или же использовать where-used.

Jelena написала:

По-любому должны быть стандарты development и документация. Правда заставить все 15 человек следовать стандартам и писать документацию - это уже отдельная проблема. Тут вон дай бог каждого принудить хоть тексты сообщений не писать прямо в коде. :roll:

По-любому. Но одно дело документация, которой как Вы правильно сказали не все умеют пользоваться, другое дело "Where-Used", который нам все покажет и расскажет.

Jelena

Я бы лично не стала заморачиваться никакими классами, а максимум попыталась все собрать в какой-нибудь include или ФМ. Ход мысли примерно такой:
1) Многие мои коллеги - зубры мейнфрейма и ко всяким там модным веяниям типа ООП относятся подозрительно. 15 человек будет проще подбить следовать стандарту, если он будет использовать более привычные им технологии.
2) Ctrl-F работает куда быстрее, чем "where-used".

Вообще наверное имеет смысл скорее поинтересоваться мнением 15 коллег, чем форума. Если они не поддержат вашу инициативу, то грош цена будет этому "where-used", если кто-то будет продолжать все делать по старинке. Чистое IMHO, конечно.

А что вы, кстати, с существующим кодом будете делать - переписывать? Нам бы на это время не дали...

Maxus

Jelena написала:

Я бы лично не стала заморачиваться никакими классами, а максимум попыталась все собрать в какой-нибудь include или ФМ. Ход мысли примерно такой:
1) Многие мои коллеги - зубры мейнфрейма и ко всяким там модным веяниям типа ООП относятся подозрительно. 15 человек будет проще подбить следовать стандарту, если он будет использовать более привычные им технологии.
2) Ctrl-F работает куда быстрее, чем "where-used".

Если так рассуждать, зачем нам вообще какие-то новые технологии и решения. Давайте все делать по-старинке, так надежнее. И соберем весь код в одном include на 20000 LOC. Весело будет.

Jelena написала:

Вообще наверное имеет смысл скорее поинтересоваться мнением 15 коллег, чем форума. Если они не поддержат вашу инициативу, то грош цена будет этому "where-used", если кто-то будет продолжать все делать по старинке. Чистое IMHO, конечно.

Коллеги в курсе, не стоит беспокоиться. Если решение будет разумным и логичным, то поддержат - никуда не денутся.

Jelena написала:

А что вы, кстати, с существующим кодом будете делать - переписывать? Нам бы на это время не дали...

Переписывать будем по ходу изменений. Лучше какая-никакая, но система, чем непонятно что.

Maxus

Небольшой пример (после изменений концепции)

Для создания новых сегментов ORDERS05:

Code:

ycl_e1edp01->append( ls_e1edp01 ).
ycl_e1edp05->append( ls_e1edp05 ).

Для изменения:

Code:

ycl_e1edk01->modify( ls_e1edk01 ).

Таким образом, все изменения в IDOC отслеживаются с помощью "Where-Used"

Правила форума

OOP при создании структуры IDOC

Кто сейчас на конференции