Как правильно хранить статичный набор начальных данных в классах?

[sukhanchik]

Еще примеры вспомнил.
Классы NumberSeqReference* (автоматическое заполнение таблицы на закладке Номерные серии).
Классы ReleaseUpdate* (автоматическое формирование списка пакетных заданий для скриптов - обновления версии при прохождении контрольного списка обновления).

Суть: есть некий набор (небольшой) параметров, каждый из которых умещается в своем поле таблички (для номерных серий - см метод load, в котором каждый из нас по сути прописывает заполнение этих полей).
Дальше выполняется метод create(), который уже "по-умному" дополняет запись и вставляет/обновляет ее по мере необходимости (допустим, мы изменили HelpText в методе load - так несмотря на то, что запись в табличке NumberSequenceReference уже существует - то HelpText будет обновлен).

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

[Андре]

Я обычно выбираю разновидность варианта 1.3 - класс, содержащий Set/Map/List других классов. То есть, работаю с двумя сущностями - Entity и EntityCollection.

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

Как минимум в классе Entity я добавлю аналог метода toString(), для удобного отображения его содержимого в infolog-е, и методы set()/get(), поставив точку останова на которых другие разработчики смогут контролировать работу с этими классами.

Кроме того, в данном варианте, код работающий с этими классами выглядит гораздо понятнее и проще, за счет того, что все низкоуровневые манипуляции с данными (conpeek/conpoke/работу с индексами/проверки) я прячу в методы этих классов, имеющие говорящие имена и сразу понятные разработчику.

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

[mazzy]

Цитата:

Сообщение от Андре

Я обычно выбираю разновидность варианта 1.3 - класс, содержащий Set/Map/List других классов. То есть, работаю с двумя сущностями - Entity и EntityCollection.

Entity на базе чего-то стандартного?
или полностью свое?