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

[саша40]

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

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

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

[Sibedir]

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

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

А, вот, если я обращаюсь к методу или свойству через родительский класс или интерфейс, то лично меня вообще не волнует, к какому я классу там обращаюсь. И в ран-тайме и не в ран-тайме.

А если у вас у однотипных классов разные родители но одинаковые имена свойств, то можно и RTTI (Человек_Борща +1). Но я вам просто настоятельно рекомендую пересмотреть свои взгляды на ООП.

[StriderX]

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

А, вот, если я обращаюсь к методу или свойству через родительский класс или интерфейс, то лично меня вообще не волнует, к какому я классу там обращаюсь. И в ран-тайме и не в ран-тайме.

Чтобы к чему-то обратиться, это что-то должно появиться\инстанцироваться. Это мне кажется самый интересный момент в задаче - кто, где и когда создаёт объект для нашей коллекции\менеджера. То, что у объекта может быть некий интерфейс доступа - это совсем другой вопрос =-)

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

Но я вам просто настоятельно рекомендую пересмотреть свои взгляды на ООП.

Постоянно пересматриваю, мы все несовершенны %)

[Stilet]

Давно уже реализовал.

Ану ж похвастайся )

[Sibedir]

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

Чтобы к чему-то обратиться, это что-то должно появиться\инстанцироваться. Это мне кажется самый интересный момент в задаче - кто, где и когда создаёт объект для нашей коллекции\менеджера.

Честно, ничё не понял. Ты что, хочешь чтобы твоя программа работала с любой коллекцией вООбще. Тут ИИ нужен или программа-телепат.
В том то и дело, что ...

То, что у объекта может быть некий интерфейс доступа - это совсем другой вопрос

Если класс заранее не ясен, то ИМЕННО ТАК.

Самый наглядный пример такого подхода - OLE-объекты. "Пихай что угодно куда угодно".

[StriderX]

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

Честно, ничё не понял. Ты что, хочешь чтобы твоя программа работала с любой коллекцией вООбще. Тут ИИ нужен или программа-телепат.
В том то и дело, что ...

Если класс заранее не ясен, то ИМЕННО ТАК.

Самый наглядный пример такого подхода - OLE-объекты. "Пихай что угодно куда угодно".

Перечитайте постановку задачи =-)

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

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

Здесь практически явно указывается на некий TList<T : TSomeBaseClass, constructor> или что-нибудь вроде TList<T : IComparable, IClonable, constructor> =-)
Мне не совсем понятно с чем именно вы не согласны и почему считаете, что задача в самом общем виде не имеет решения %)

[Sibedir]

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

... и почему считаете, что задача в самом общем виде не имеет решения %)

Я так не считаю. Задача имеет вполне чёткое и рациональное решение и оно заключается в использовании интерфейсов или наследования или БД.

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

Здесь практически явно указывается на некий TList<T : TSomeBaseClass, constructor> или что-нибудь вроде TList<T : IComparable, IClonable, constructor>

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

// Добавлено -----------------------------
Вообще постановка задачи требует уточнений и конкретизации сути вопроса.

[StriderX]

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

Давай пример.

Так-то это на большую статью тянет. Попробуем предельно сжато. У нас изначально написано:

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

Пока менеджер знает с чем работает, вопросов и проблем нет. Вопрос: можно ли написать такой менеджер, который бы не знал с чем конкретно работает, но при этом были бы легальны и 1, и 2 строка.
Как сделать легальной запись 1 (CustomManager.ConstructObject)?
Нам нужен способ конструирования:
- дженерик с ограничением на конструктор. Тогда мы пишем instance = T.Create();
- дженерик с ограничением на record. Тогда мы сможем писать instance = new(T). Этот вариант забагован, в qc отмечено исправление в XE7 ( http://qc.embarcadero.com/wc/qcmain.aspx?d=123881 ).
- некая фабрика-конструктор. Эту мы поставляем при создании самого менеджера, что-то типа: TCustomManager.Create(TFactory.GetC ustomInstantiator())
- некий указатель на фукнцию или анонимка: TCustomManager.Create(SomeConstruct ionCallback).
Как сделать легальной запись 2 (CustomManager.Data[i].CustomField := value)?
Нам нужен способ конкретизации того, что хранит обезличенный менеджер:
- базовый класс в иерархии наследования без некоторых сопроводительных данных не позволит провести обратное приведение;
- интерфейс вообще невозможно привести к исходному виду без метапрограммирования - в этом его суть;
- дженерик инстанцируясь в компил-тайме (и только в нём) делает запись 2 легальной "из коробки".
За бортом остались игры в диспатчеры (OLE-объекты, кастом варианты и т.п.) - эти разрешат запись 2, но запретят компилятору проверять её на ошибки\корректность.

[Sibedir]

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

Так-то это на большую статью тянет.
...

OK, StriderX. Мысль с дженериками ясна. Непонимание у нас с тобой от другого. И виноват тут ТС. Вот смотри, что он пишет:

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

...

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

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

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

И мы с тобой не найдем здесь общий язык пока ТС не реализует общий интерфейс для Агента и Контракта хотя бы для какого-то набора свойств и методов. Только тогда предков всех менеджеров можно создать дженериком.
Но писать сами менеджеры для каждого класса все-таки придется. Ибо

МенеджерАгентов.Объект[1].ИзменитьСтатус(стаНедобросовестный );

мне сложно представить "Недобросовестный" контракт. Неуточненных типов в дженерике столько может вылезти... Запутанность такая получится, что для 5-6 проще каждый сделать отдельно. Конечно, мнение довольно субъективное, но у агента и контракта общего столько же, сколько у кота и его миски. Да они могут быть в одном доме и иногда пересекаться. Но склад посуды и приют для животных - это вообще разные вещи.

[StriderX]

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

Но склад посуды и приют для животных - это вообще разные вещи.

Да, в этом суть дженерик-контейнеров. Им абсолютно всё равно с чем иметь дело. Весь дополнительный функционал они запрашивают в виде интерфейсов. Хочешь отсортировать? Прям по месту сконструируй компаратор и отдай его интерфейс - TArray.Sort<TSomeUnknownData>(myArr ay, TComparer<TSomeUnknownData>.Constru ct(Exit(IfThen(blabla))));
Если речь о том, чтобы обезличить одной кнопкой сами контейнеры, то нужна поддержка ко-контравариантности. В Delphi таковой на данном этапе нет.