и зачем это требование тащат из регламента в регламент?
одних инклудов?
в смысле в главном файле только инклюды?
Открой редактор. Нажми F1. Выбери ветку ABAP - Programming Guidelines - Structure and Style - Source Code Organization - Source Code Modularization читай до полного просветления
имхо, согласен с Антоном, для меня это дикая дичь. но так же скажу, что это дело привычки
Там все аргументы сводятся к тому, что удобно будет большие программы редактировать параллельно, т.к. блокировка на уровне инклуда делается. Это правда полезно, только типовой паттерн, когда все дефинишены в одном инклуде, а имплементейшены в другом, явно не про то)
это именно про него. .. не говоря уж вообще о том, что нефиг локальные классы делать...
До сих пор отдельная боль, что даже в глобал классах блокировка в случае добавления/удаления метода или изменения сигнатуры вешается на всю область класса :( вся красивая параллельность редактирования больших отчётов убивается нафиг
Ну залочишь ты один инклуд ради правки в одном классе или подпрограмме, заодно и всю остальную бизнес логику, если нет деления именно по функциям
дифинишн можно в одно, а имплементейшены в разные
А потом кто-нибудь решает переложить объекты из одного запроса в другой и забывает часть класса
Я бы и дефинишены в разные)
я бы тоже, но тогда проблемы бывают, и без defferred не обойтись
Дефинишены отдельно от имплементейшинов как раз и позволяют не делать deffered
если подходить формально, то разделение дефинишена и имплементейшена поможет избежать необходимости определения класса в месте глобального определения инстанса через class definition deffered. Т.е., как я понимаю, мысля у авторов была такая: 1) инклюд с дефинишеном класса 2) инклюд с определением глобального инстанса класса 3) инклюд с имплементейшеном класса Ну и если заполировать это еще тем, что в проге может быть несколько классов объявлено, то получается все достаточно логично
И мы почти получили c++ :)
Обсуждают сегодня