Привет, немного пятничная тема.
Вот допустим вам надо написать программу (report): селекционный экран, программа что-то там делает, выводит данные в ALV, как-то с ними взаимодействуют пользователи.
Где-то 5-10 тыс. строк. Какие-то части возможно будут использоваться в другом месте.
Abap 7.0, так что Eclipse использовать нельзя.
Как будете писать? Form, FM, SE24, локальный класс в отдельном инклюде...
Используете глобальные переменные? Как потом повторно используете отдельные части в других программах.

Если программа делает потенциально нужную в других местах выборку данных - выборку оборачиваю в ФМ,
а так формы и события ЛБД/экранов

А как понял что 5-10 тыс строк будет?

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

Раньше я писал все в формах:


После меня потянуло в ОО и я стал делать типа контроллера в локальном классе.


Но что-то мне этот подход тоже не очень нравится.

В se24 кажется ковыряться очень долго, хотя надо попробовать.
Вообще, конечно, SAP добавил ОО в ABAP достаточно коряво, мягко говоря. Даже удивляет что не кто на это не ругается. Определение метода в одном месте, реализация в другом.

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

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

А вот обертка в ФМ для последующего повторного использования операций чтения данных и операций записи данных (т.е. отделение интерфейса от обмена данными с БД)- наоборот очень позитивная практика.

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

Ну и посмотрите тут
https://github.com/SAP/styleguides/blob ... eanABAP.md
и тут
https://github.com/ilyakaznacheev/abap-best-practice

ООП нужно если програму разрабатывают много групп программистов , чтобы распределить ответственность за отдельные части программы. Иначе будет коллективная безответственность. Для 10 тыс. строк ООП не нужно.

[Условия: разработка относительно большая, разрабатывается "с нуля", нет никаких ограничений со стороны архитектуры САП или особых требований при постановке задачи].
Предпочту локальные классы. Повторно используемый код - в локальных классах в отдельных инклудах. Библиотеку классов можно сделать и через глобальные классы, но только если разработка уж очень большая, или же если эти классы сразу же хорошо продуманы, и правиться почти не будут (что в реальности - редкость). ФМ-ы - только в случае повторно используемых экранов, при этом оборачивая их вызовы методами какого-то класса из библиотеки. Подпрограммы использовать не буду.
Глобальные переменные - зло. Использую только вынужденно - при работе с экранами.
Если инклуд - подключаю к нужной программе. Если глобальные объект - он доступен сразу.

Я вот больше согласен с LAT.
Да городит ООП огород с фабриками и прочими абстаркциями в такой программе не нужно, но и использовать формы бы не стал.
Делал бы все на локальных классах, по сути особо ничего не поменяется с точки зрения архитектуры, но у методов есть некоторые плюсы:
1) опциональные параметры(если ими не злоупотреблять)
2) более короткий синтаксис
3) легче читается, если в программе много другого кода по работе с классами, например, BOL

Видеть вызовы perform внутри такого кода как-то странно.
4) возможность делать функциональные методы, что в свою очередь позволяет обойтись меньшим количеством переменных.
5) классы позволяют сгруппировать данные и логику работы с ними, уйдя при этом от глобальных данных, при этом позволяя достаточно эффективно кэшировать данные в атрибутах класса.

ФМ для организации обособленной логики которая включает в себя экраны, работу по RFC, экстракторы для BW(что и так понятно...) и т.д

Всем спасибо за ответы.
А почему локальные классы а не глобальные? В чем отличие? (Я начал в локальных, только потому что мне так писать быстрее и так весь код в исходниках - как в других языках, без вкладок и окошек se24).
Как организовать локальные классы? (Я по аналогии с java - 1 класс = 1 инклюд)

И какая разница будут правиться глобальные классы или локальные?
И что такое функциональный метод? (Когда только importing и returning value?)

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

С точки зрения использования в одной программе - условно никакого.
Глобальные классы доступны во всех программах(поэтому - глобальные), т.е. вы можете переиспользовать их в других программах.

Тут как вам проще, законов нет.

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

Ну по сути да, pure function.

чем грозит?

Да, почему не надо? Как использовать куски кода в других местах? Выделять в ФМ или в глобальный класс?
Тогда даже процедуры выглядят лучше, если конечно не используют глобальные переменные внутри, т.к. их можно использовать повторно.

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

инклуд с классом включать только в голову, и не будет проблем