Как организовать данные? (Единый доступ к разным классам)

[Sibedir]

Перечитал вопрос еще раз.
StriderX дело говорит. Дженерик менеджеров позволит автоматизировать многое. Но без интетфейсов и/или наследования (для создателей, дубликаторов и пр.) не обойтись.


м-дя. Пока 100 раз не перечитаешь - вопрос не поймешь. Короче, автору слово.

[Sibedir]

Тема так и просит примера: Дженерик списка.zip
Замечания, конечно же, приветствуются.

В принципе всё понятно, но тем не менее:
1. Как проще у TAgent переопределить AssignTo, чтобы туда кто попало TPersistent не пихал, а только TAgent. Понимаю, что туповатый вопрос, но не очень хочется каждый раз переписывать еще и Assign.

2. Откуда ноги растут у ошибок после закрытия фомы при финализации системных модулей.

Сообщение от Debugger Exception Notification

Project Project1.exe raised exception class EInvalidPointer with message 'Invalid pointer operation'.
---------------------------
Break Continue Help

Сообщение от Error

Runtime error 217 at 00407479
---------------------------
ОК

И

Сообщение от Debugger Exception Notification

Project Project1.exe raised exception class $C0000005 with message 'access violation at 0x0040c896: read of address 0x01e50d54'.
---------------------------
Break Continue Help

Сообщение от Error

Runtime error 216 at 0040C896
---------------------------
ОК

Delphi XE5
Если запускаю не из под среды - вылазит только первая нога... ошибка


PS:
Перечитал вопрос еще раз.
Не. Базы данных. Однозначно.г

[Nhara]

Спасибо за ответы!

Просто одним наследованием TAgent и TContract от TItem решить не получается, т.к. у TItem нет полей, которыми могут обладать первые. Из TItemManager не получится достать поле TAgent.AgentStatus; Писать
TAgent(МенеджерАгентов.Объект[x]).AgentStatus неудобно, таки.

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

TItemManager = class(TObject)
Item: array of TItem;
procedure NewObject;
end;

TAgentManager = class(TItemManager)
Item: array of TAgent; //TItem child
end;

Чувствовал, что так делать нельзя, но RAD XE7 приняло код и получается работать с полями. Правда на этом все - вызов методов родителя из TAgentManager, при обращения к "общим" полям (для TItem и TAgent) дает Access Violation;

StriderX, создает объект для менеджера, желательно, сам менеджер, но не обязательно. По большому счету, не важно даже где он создает и где этот массив хранится.
Важно лишь иметь удобный способ доступа и управления этими данными. Поэтому я и спросил, может быть существует какой-то иной способ организации? С этими данными придется работать очень много - обращаться к отдельным полям и выполнять типичные процедуры.
Можно ли применить интерфейсы? и как? Базы данных?

Sibedir, метод СоздатьОбъект для Менеджера Контрактов и Менеджера Агентов один и тот же, создать, присвоить номер - техническая работа по инвентаризации. Разница только в классе объекта.
У Контракта и Агента общего не очень много. Но их всех надо создавать, сохранять, менять местами особым способом, с изменением внутреннего индекса, обновлением базы индексов, и т.д., там тоже порядочно. Странно будет просто дублировать один и тот же код для 5-6, мб больше различных менеджеров, и самое главное его менять, если что

[StriderX]

Сообщение от Sibedir

1. Как проще у TAgent переопределить AssignTo, чтобы туда кто попало TPersistent не пихал, а только TAgent. Понимаю, что туповатый вопрос, но не очень хочется каждый раз переписывать еще и Assign.

2. Откуда ноги растут у ошибок после закрытия фомы при финализации системных модулей.

Delphi XE5
Если запускаю не из под среды - вылазит только первая нога... ошибка

XE5 - это бедствие и катастрофа, ничего более нестабильного никогда не было (ну если забыть про 2009, но оно быстро пролетело) %)
Первый стабильный дженерик у нас был в 2010, более менее оно работает в XE. Относительно хорошо оно работает в XE7.

В порядке бреда: нормальные герои всегда идут в обход. Обход у нас - это records. Вот пусть стаб с ними и страдает со своими клонированиями и копированиями )

[Sibedir]

StriderX, спасибо за код. Сижу изучаю. Интересно. Но слишком сложно для меня
Попробывал по другому. Переделал на

  TManager<T: TData> = class (TList)

Всё опять работает, но при финализации - быдыдыщ.
Делал всё сегодня на бегу м/у домашними делами. И вот... Упростил всё как смог. Привел всё в понятный мне (надеюсь не только мне) вид. И нате вам. Ошибка при закрытии в какой-то момент пропала. Я даже не понял в какой. Попробовал вернуть последние изменения. Ошибки нет
Фиг знает чё, но получилось - что получилось (XE3): Дженерик списка.zip

Добавлено -----------------------------------------
ХА-ХА-ХА. Загрузил с форума свою предидущую версию. Вот же оно:

  AM1 := TManager<TAgent>.Create;
  AM2.Free;

Добавлено -----------------------------------------
И еще, Nhara, ну всё-таки

Сообщение от Nhara

Как организовать данные?

...динамические массивы объектов - 5-6 разных классов.
Над ними нужно делать однообразные операции (создавать, присваивать уникальный ID, менять порядок, следить за переполнением размера массива, которых их содержит итд).

МенеджерКонтрактов...

МенеджерАгентов...

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

Речь явно идет о базе данных. Да в той же 1С приличный одинесник это всё вам лучшим образом организует да еще с привязкой к бухгалтерии. Если это не учебное задание ну или как у меня "для сэбэ", если это реальная производственная задача, наймите соответствующих специалистов. Ты, кстати, из какого города сам.

[StriderX]

Сообщение от Sibedir

StriderX, спасибо за код. Сижу изучаю. Интересно. Но слишком сложно для меня

Это потому, что там бредогенератор работал - много лишнего. Прокси-тип имеет смысл делать только, если мы хотим отдельно от контейнера куда-то передавать элемент аргументом - чтобы у нас был единый тип для этого (простой указатель на record будет несовместим с тем указателем, что построит дженерик). Поэтому там 5 минут рефакторинга и всё станет простым %)
Если без шуток, то подход выглядит симпатичным только если запись действительно в контексте задачи является записью.