насколько приемлем такой конструктор?

← →
umbra © (2006-11-25 13:38) [0]

Я создаю некий набор наследников от TCollection и, соответственно, от TCollectionItem. Поскольку значения свойств для элементов коллекций я получаю из строк текстовых файлов, то в базовом абстрактном классе элемента я перегрузил конструктор TCollectionItem, добавив еще один параметр.

TAccountEntry = class(TCollectionItem) {..............................................} public constructor Create(Collection: TCollection; Data: String); reintroduce; overload; {.............................................} end;

При создании наследника базового класса (TPFUPSVEntry = class(TAccountEntry)) возможна ситуация , когда данных еще нет (это известно до создания). Поэтому его конструктор имеет вид

constructor TPFUPSVEntry.Create(Collection: TCollection; Data: String); begin if Data = "" then inherited Create(Collection) else inherited; end;

Вопрос заключается в том, какие подводные камни возможны при такой схеме. Заранее спасибо!

← →
Palladin © (2006-11-25 13:43) [1]

При сериализации, чтения коллекции возникнут. Рекомендую вместо перепредставления конструктора добавить еще один.

← →
umbra © (2006-11-25 14:12) [2]

посмотрел на то, что написал, и подумал: а зачем я это в наследнике делаю, если можно в базовом классе!

2 Palladin © (25.11.06 13:43) [1]

Честно говоря, не понял о чем идет речь :)

← →
umbra © (2006-11-25 14:22) [3]

2 Palladin © (25.11.06 13:43) [1]

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

решает ли перенос проверки строки на наличие содержания в базовый класс проблему о которой Вы говорили?

← →
Palladin © (2006-11-25 14:35) [4]

> umbra © (25.11.06 14:22) [3]

чтение коллекции из потока, имеется в виду, при сериалиализации компонента, если вдруг созданную коллекцию придется сохранять, а потом считывать. это первое что пришло в голову по поводу камней. сюда же относится и все что связано с созданием коллекции не "в ручную"... когда VCL рулит созданием ее item"ов... это логически вытекает...

> решает ли перенос проверки строки на наличие содержания
> в базовый класс проблему о которой Вы говорили?

вот уж не знаю, решает в принципе - если не трогать конструктор Create...

← →
GrayFace © (2006-11-25 15:03) [5]

О том, что reintroduce не нужен. Вот только не понятно, что должен делать код Create. По идее, этот пустой inherited вообще не должен транслироваться.

Это был ответ на [2] :)

> сериалиализации

эко меня замкнуло... )

2 GrayFace © (25.11.06 15:03) [5]

> О том, что reintroduce не нужен.

а чем он мешает? как следует из справки, этот спецификатор всего-навсего говорит компилятору не генерировать предупреждение о скрытии родительского конструктора.

2 Palladin © (25.11.06 14:35) [4]
> если не трогать конструктор Create...

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

насколько приемлем такой конструктор? Найти похожие ветки