Есть класс. Он находится в отдельном INCLUDE. Этот класс подключается в группе функций.
Из программы вызываю ФМ этой группы функций. Этот ФМ вызывает подпрограмму обратного вызова (это у меня своя реализация REUSE с блэкджекомишлюхами) и в качестве параметра этой подпрограммы передается параметр "type ref to CL_МОЙ_КЛАСС". Соответственно в программе я тоже подключаю этот класс. Однако при вызове получаю дамп, так как хотя INCLUDE один, но раз подключен дважды, то для ABAP-а это разные классы. Сделал в подпрограмме параметр "type ANY". Программа в дамп не падает при вызове. Но мне то нужно чтобы тип был не ANY, а "ref to CL_МОЙ_КЛАСС".
Можно ли как-то это исправить? Или все-таки сделать преобразование?
т.е. схема такая

представь, что класс это тип, объект класса это переменная данного типа,
в каждой программе локальные типы таковыми и являются и имеют врем. идентификатор (Прогр=..., Тип=%_T000...).

если тип объявлен в инклуде, который входит в две разные программы,
он по сути как лист в тетрадке - когда компилятор собирает программу,
строится дерево инклудов по d010inc, затем все инклуды склеиваются в большой исходник,
который разбирается abap-грамматикой (синтаксич. проверка);
а значит получается два разных больших исходника-программы, и в каждой свои лок. типы,
локальный тип адресуется примерно так - (программа, лок.тип),
и для runtime типы будут разными: (прогр А, лок класс А) и (прогр Б, лок класс Б).

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

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

В общем выкрутился. Убрал включение класса из группы функций. Так что теперь группа функций о классе ничего не знает. По идее это даже лучше, так как позволяет использовать этот ФМ с разными версиями класса.

В ERP появилась возможность работать с глобальными классами на основе исходного текста. Так что перетащить глобальный класс между системами - не проблема.

GoF и SAPLink смотрят на ваше решение как на ... Ну вы поняли? Зачем отказываться от нормального решения как в части совместимости(собственно глоб.интерфейс и совместимость по нему - это нормальное решение), так и в части переносов(SAPLink)?
Наследование и использование интерфейсов в ООП - отличные плюшки технологии. Что ж вы себя лишаете всех бонусов?

Да я и сам смотрю также. Но действительность такова, что проще хранить в одном INCLUDE.
Даже стиль именования классов может отличаться в разных системах. А в INCLUDE у меня внутренний класс, который я как хочу, так и назову.


Системы отличаются версиями и что есть в одной системе, может не быть в другой. INCLUDE вроде везде есть.

p.s.Мне тут как-то пришлось дорабатывать программу (хотя существовала мной же написанная программа с аналогичным функционалом) потому что СОГЛАСОВЫВАТЬ документацию на эту новую программу нужно у начальства и ПРОЩЕ дать задание программисту вставить в другую программу аналогичный функционал. Проще для постановщиков, но, само собой, не для меня. Так что правильные решения не всегда подходят в практических условиях.

Так тогда вам и инклюд не поможет


Каждый работает, как привык.
Кто мешает вам один раз написать документацию на свою программу?

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

То есть портируемый во все системы класс не нужен начальству?
Тут или с начальством проблемы, или с документацией...
Сорри за оффтоп

в принципе, можно попробовать инклуд с классом преобразовать в пул классов или обычный пул,
(тут наверное без разницы, т.к. класс не словарный и глобальной видимости не возникнет)
и сделать подпрогр. фабрику которая будет выдавать обезличенные ссылки,
тип которых для внешних программ будет одинаковым (пул, %_t000..).

Я раньше тоже так думал и поступал. Но всё время ощущал неудобства из-за невозможности пользоваться словарём. Хорошим решением для меня стала собственная система на ноутбуке а так же утилита для переноса объектов разработки. Теперь с превеликим удовольствием пишу глобальные классы, код становится более прозрачным. На всякий случай использую уникальные префиксы для своих глобальных и словарных объектов. В случае, если нужно поменять их имена, сначала импортирую в систему клиента со своими именами, а потом копирую в нужные стандартными средствами SAP. Свои потом удаляю. Если не хочу светить класс как глобальный, например набор собственных утилит, экспортирую его в исходный текст штатным средством - в новых системах есть кнопочка, в старых (вплоть до 4.6D) прога SEO_SHOW_CLIF_INCLUDES или ручная команда show_clif в se24.

Штатный импорт из исходного в глобальный есть даже в 4.6D, если не ошибаюсь.

Parazit а из-за такого копирования туда-сюда не возникает проблем с обновлением класса? Т.е. добавил новые фишки в системе 1 и нужно их вставить в систему 2?
С INCLUDE все понятно, обновил текст и все. А вот с глобальным классами, они тоже при экспорте/импорте обновляются?

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

Параметр ref to object + динамический вызов метода.