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

[Nhara]

Добрый вечер!
Посмотрел поиск, понял только, что то как я хочу сделать - невозможно)
Поэтому хочу попросить о помощи, как организовать данные?

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

Я не хочу писать 6 одинаковых классов-менеджеров, у которых разница только в классе объекта, которым они манипулируют

В идеале стремлюсь к удобству использования.

МенеджерКонтрактов.СоздатьОбъект; //создаст, присвоит номер, проверит массив
МенеджерКонтрактов.Объект[Последний Созданный].ДатаЗаключения:=EncodeDate(2015,2,3);
МенедежерКонтраактов.Дубликат(59); //создаст дубликат 59ого номера
и т.д.

МенеджерАгентов.СоздатьОбъект;
МенеджерАгентов.Объект[Последний Созданный].ОкончаниеСрока:=EncodeDate(2016,3,21);
МенедежерАгентов.ВНачало(59);
МенеджерАгентов.Объект[1].ИзменитьСтатус(стаНедобросовестный);

Так не выходит, потому что менеджер управляет предком Агента и Контракта, у которого нет свойств последних

Может быть есть другие способы?

[StriderX]

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

Добрый вечер!
...
Может быть есть другие способы?

В порядке изучения: дженерики, интерфейсы, метаклассы. Эти трое позволяют делать что угодно. Для первого приближения будет более чем достаточно дженериков.

[саша40]

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

[Stilet]

Над ними нужно делать однообразные операции

Ну так отнаследуй их от одного базового класса.

Вместо типизированных указателей на объекты храни нетепезированные(Pointer).

Плохая идея. Чревата костылями с приведением типов.

[саша40]

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

Плохая идея. Чревата костылями с приведением типов.

Зато памяти и нервов экономит дохрена. Достаточно завести свою переменную в таком объекте с указание какого типа объекты там хранятся. В результате не надо будет мучится с проблемами о том, как узнать какого типа объект в массиве. Достаточно будет проверить переменную класса(приватное поле класса, как раз то что надо).

[Пепел Феникса]

Сообщение от саша40

Зато памяти и нервов экономит дохрена. Достаточно завести свою переменную в таком объекте с указание какого типа объекты там хранятся. В результате не надо будет мучится с проблемами о том, как узнать какого типа объект в массиве. Достаточно будет проверить переменную класса(приватное поле класса, как раз то что надо).

памяти не экономит, нервов тоже(скорее наоборот).

как раз таки генерики или наследование верный вариант.
читаем про ООП.

[Stilet]

В результате не надо будет мучится с проблемами о том, как узнать какого типа объект в массиве. Достаточно будет проверить переменную класса(приватное поле класса, как раз то что надо).

Отето ты выдал О_о... Стоять аль падать, даже не знаю... Теперь придется всю свою жизнь в ИТ переосмысливать )
Сам то хотя бы раз попробуй реализовать то что сказал.

[Sibedir]

Наследование поддерживаю - самое оно. На то ведь оно и ООП.
Ну или базы данных.

[StriderX]

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

Наследование поддерживаю - самое оно. На то ведь оно и ООП.
Ну или базы данных.

Если мы не хотим перегружать "СоздатьОбъект", а это условие задачи (не хочу писать 5-6 менеджеров), тогда нам нужен способ создания "того, не знаю чего". Дальше всё решает вопрос "а когда узнаю?"
Если узнаём в компил-тайме, нам помогут дженерики с требование иметь конструктор\new и указанием некоего интерфейса\базового класса (для операции клонирования, например).
Если узнаём в ран-тайме, нам помогут интерфейсы и фабрики.
Если мы даже в ран-тайме понятия не имеем, тогда начинается метапрограммирование и игра в диспатчеры =-)

[Человек_Борща]

ООП с обращением к RTTI.