Добрый день,

возникла необходимость определить в классе относительно большое число констант (~2000).
Через стандартный интерфейс работать с этим чудом не очень удобно.
Подскажите, не существует ли случаем красивого способа подключить файл с ними к классу
или включить подпапки в интерфейсе или еще чего-нибудь? =)

Ух ты , а как с ними работать-то потом?
CASE на 2000 случаев?

Можно завести кучу абстрактных классов, наследуемых друг от дружки и вести необходимые константы в них. А Ваш класс сделать наследником последнего абстрактного класса и получите все свои константы. Но чего-то это как-то жестко

Может проще справочник какой-нибудь завести.

Добрый день.
Справочник придется к месту. В нем все и вести.

К слову, константы в HR ведутся в таблице.

Или можно воспользоваться признаками. PE03

Чем хороши признаки:
1) Можете наглядно просмотреть все дерево решений.
2) Очень удобно вести
3) В случае необходимости, можете вытащить программный код в виде case и использовать в программах

А если в общем о поиске решения, то тут нужно учитывать специфику. Нужно ли Вам активно переносить или вероятнее всего этим будут использовать в рамках одного проекта.

Для этих целей существует другой интсрумент. TYPE-POOL по англицки кличут, или Группа Типов на великом и могучем
Подключается к классу в секции свойства.

Ну так ужобства тоже в этом нет, еще и префиксы надо для всех выставлять.
Хотя какие могут быть вообще удобства с 2000 констант...

Сравочник, интерфейс ведения, функцию для выдерки значения и забыть об этом.

Ну удобство - момент спорный.
И с 2000 констант - трудно достижимый.
Я только к тому, что САП самолично использует для этих целей группы типов. Не более.

P.S.: Естественно если константы используются не в одной-двух разработках, а достаточно системно.

Вообще, я думаю, что если оценивать все средства, которыми это можно сделать, то их найдется множество.

Но автор не указал область применения и распространения, поэтому выбрать не имея уточняющую информацию сложно.

Согласен, но не совсем

Мы, действительно, не знаем что будет храниться в константах, но если это что-то связанное с бизнесом, например коды валюты, коды стран и т.д. то это не гуд.
В тайппуле хорошо хранить константы, скажем, необходимые для работы программы, например константы для работы с OLE, как это сделано в ole тайппуле или название иконок, как в тайппуле иконок, или то что лежит в type-pool abap.

Lars, так в этом ключевое отличие.
Константы - они константны. По определению и тафтологии
А коды валют - это справочник. С переменными значениями.
Отсюда разные средства реализации и визуализации.
Тут да, автору виднее. Вариантов ему уже озвучили много.

Честно говоря, не удивлюсь, если это какой-нибудь план счетов, че-то насмотрелся последнее время ...

Подыму-ка старую тему...

Часто в разработках приходится использовать списки каких-то фиксированных бизнес-значений - ну для примера, например, какие-то счета-исключения, список материалов, для которых логика функционала работает по-иному и прочая. Обычно этот список невелик, но разработок таких много.

Варианты реализации обычно выглядят примерно так (по мере эволюции программиста) :
1) список зашит напрямую в код
2) список хранится в настроечной табличке, для которой сделан ракурс ведения (быстро, дешево и эффективно)
3) ?

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

У кого-то есть какие-то соображения по поводу?
Наверняка есть еще какие-то способы хранения такого рода информации, о которых я не знаю, отдельно от кода.

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

Основное соображение. По-хорошему, таких списков не должно быть. Т.е если есть список каких-то материалов-исключений, то у этих материалов в ОЗМ должен стоять определенный признак и все.

Имхо, тут должен созреть не только разработчик, но и аналитик)

У меня подобная система есть. никаких особенных преимуществ не дает, просто немного экономит время при реализации разработки.

Для этой цели вполне удобно использовать "наборы" Report Painter'a (транзакции GS*). Консультанты ведут там свои списки значений, а в программе эти списки считываются и используются подобающим образом.
Пример - считываем набор с именем ZHKONT_CLEAR_RED, в котором хранятся счета, и складываем в HKONTS

Аналогично использовали списки Report-Painter. Там и вкладывать можно списки один в другой, если мне память не изменяет. И есть поле для признака, правда не очень большое, его можно использовать для дополнительного анализа.
Но, честно говоря, не кажется это удобным.