В классе ссылка на класс

← →
RASkov (2006-08-14 23:23) [0]

Народ, подскажите как сделать такую фичу.
Есть класс А и класс B

type TSingl = class FInt: Integer; ..... end; type TB = class FA: TSingl; ........ end; constructor TB.Create(ASingl: TSingl); begin //if ASingl=nil then Free; или Exit; if FA=nil then FA:=ASingl; end; function TB.GetData: Integer; begin Result:=FA.Data[1,1]*FInt; end;

Класс TSingl независимый, от него создается один единственный экземпляр.
От класса В создано некоторое число экземпляров (все время разное)
Одно поле должно содержать ссылку на экземпляр класса TSingl
Если нет экземпляра класса TSingl - не создавать В
Вот как правильно установить ссылку в классах В на TSingl
В классе В нужно будет обращаться к методам класса TSingl (читать из него данные)
При разрушении экземпляра класса TSingl нужно что бы все экземпляры класса В убили себя.
В классе В есть метод, где все время осуществляется проверка FА, там можно вызвать деструктор В

procedure TB.VerASingl; begin if FA=nil then Free; end;
Уничтожаю FreeAndNil(aA); из основного модуля (там где и создавал);
VerA Не катит.

Из основного модуля модуля например
Это только пример:

var aA: TSingl; bB: TB; .... procedure ButtonClick(... begin aA:=TSingl.Create(100,230); bB:=TB.Create(aA); Sleep(5000); FreeAndNil(aA); //bB после этого продолжает существовать. end;
Вроде все описал....
Пробовал с крышками, @, Pointer"ами.... Никак не получилось...
С указателями практически не работал. Если можно приведенный мной код подправить, добавить. Спасибо.

← →
Zeqfreed © (2006-08-14 23:30) [1]

Рекомендую придумать архитектуру получше. Сможешь привести объективные причины в пользу использования изложенной тобой схемы?

← →
RASkov (2006-08-14 23:40) [2]

> [1] Zeqfreed © (14.08.06 23:30)

Если это так сложно то буду думать что нибудь альтернативное, но хотелось бы так. Дело в том что данные содержащиеся в экземпляре TSingl"а нужно использовать во всех bВ (чтение) причем если в TSinle что то изменилось то все работают с новыми данными (одинаковыми)... И есть одно место в TSinle ссылка на bB... у TSinle струтура сложная объяснить тяжело, там есть много мест с чем могут работать bB но только один bB в этом месте может быть, там он себя и отмечает и другие если занято то туда не лезут. Вот..
Низнаю как еще объяснить...

← →
RASkov (2006-08-14 23:47) [3]

Может чето типа такого? Правильно ли это? Для данного случая..
type TSingl = class FInt: Integer; ..... end; type TS = class of TSingl; type TB = class FA: TS; ........ end;

← →
Zeqfreed © (2006-08-14 23:52) [4]

Нет. Не стоит писать наугад :)

← →
RASkov (2006-08-15 00:41) [5]

> [4] Zeqfreed © (14.08.06 23:52)
> Нет. Не стоит писать наугад :)

>ALL
Подскажите тогда как это делается?

← →
DiamondShark © (2006-08-15 01:24) [6]

> Класс TSingl независимый, от него создается один единственный
> экземпляр.

Незачем такому классу вообще существовать.
Всё вынести в модуль.

← →
evvcom © (2006-08-15 09:12) [7]

> Класс TSingl независимый, от него создается один единственный
> экземпляр.

Ну и создай его единожды в initialization и пусть живет до finalization, ссылки из TB убрать, пусть обращается через глобальную переменную.

← →
StriderMan © (2006-08-15 10:43) [8]

унаследуй все от TComponent, объекты класса TB создавай с OWNER"ом TSingl, соответственно при разрушении TSingl, он прихлопнет всех своих компонентов. из объектов TB до TSingl можно достучаться TSingle(Owner)

← →
StriderMan © (2006-08-15 10:49) [9]

> evvcom © (15.08.06 09:12) [7]
> Ну и создай его единожды в initialization и пусть живет
> до finalization, ссылки из TB убрать, пусть обращается через
> глобальную переменную.

ИМХО некрасиво это. в Initialization код выполняется еще до Application.Initialize, что резко сокращает возможные действия в конструкторе такого класса. да и от глобальных переменных, тоже ИМХО, лучше избавляться при возможности.

> да и от глобальных переменных, тоже ИМХО, лучше избавляться
> при возможности

Это почему? Согласен, если объектов много, но если экземпляр должен быть в приложении один, то глоб.переменная - самый лучшее решение. См. VCL объекты Application, Screen и др.

> в Initialization код выполняется еще до Application.Initialize,
> что резко сокращает возможные действия в конструкторе такого
> класса

обычно, такие пользовательские глобальные объекты нужны не для взаимодействия с объектом Application. Конечно, нужды у всех разные бывают, и я могу ошибаться на этот счет. И тем не менее, мне всегда хватало "возможных действий в конструкторе такого класса"

> evvcom © (15.08.06 12:18) [10]
> Это почему? Согласен, если объектов много, но если экземпляр
> должен быть в приложении один, то глоб.переменная - самый
> лучшее решение. См. VCL объекты Application, Screen и др.

ладно, убедили:) тогда маленькое уточнение: в конструкторе такого объекта лучше все же проверять, что он еще не создан. на будущее.

> evvcom © (15.08.06 12:25) [11]
> > в Initialization код выполняется еще до Application.Initialize,
> обычно, такие пользовательские глобальные объекты нужны
> не для взаимодействия с объектом Application. Конечно, нужды
> у всех разные бывают, и я могу ошибаться на этот счет. И
> тем не менее, мне всегда хватало "возможных действий в конструкторе
> такого класса"

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

initialization raise Exception.Create("");
RunTime Error.

Конечно если заранее предусмотреть все возможные моменты, то ничего страшного.

вообще "по-уму" это делается несколько не так. организовывается система "подписчиков", которые регистрируются и получают уведомления об изменениях. сами подписчики вовсе не должны знать, какой там класс или что ещё хранит значение. тут всё просто: подписался -- получаешь. отписался -- перестал. можно ещё предусмотреть ситуацию, когда источник подыхает (буде такое возможно). всё. никаких извратов, никакой путаницы с указателями.

В классе ссылка на класс Найти похожие ветки