Почему так пишут компоненты?

← →
Prohodil Mimo © (2005-10-19 23:51) [0]

Посмотрел исходники VCL, довольно часто попадаются компоненты, типа (TCustomComboBox и TComboBox).
Зачем нужно было делать TCustomComboBox, если в TComboBox не произошло никаких изменений, а только перечислили свойства из TCustomComboBox. Почему TCustomComboBox сразу не назвали TComboBox?
И такое бывает не редко.

И ещё, влияет ли наследование на кол-во операций или при компиляции всё сольётся в одно целое?

ЗЫ. смотрел в Д3.

← →
Kerk © (2005-10-19 23:52) [1]

Это чтоб ты мог наследоваться от TCustomComboBox.

← →
Джо © (2005-10-20 00:12) [2]

> а только перечислили свойства из TCustomComboBox.

Не просто перечислили, а "подняли" уровень видимости до published.

← →
Игорь Шевченко © (2005-10-20 00:21) [3]

> Зачем нужно было делать TCustomComboBox, если в TComboBox
> не произошло никаких изменений, а только перечислили свойства
> из TCustomComboBox.

Чтобы можно было делать наследники с ограниченным набором public и published свойств :)

← →
Prohodil Mimo © (2005-10-20 01:27) [4]

Джо © (20.10.05 0:12) [2]
Не просто перечислили, а "подняли" уровень видимости до published.

А сразу этого сделать нельзя было?

← →
kaif © (2005-10-20 02:13) [5]

Согласен с Игорь Шевченко © (20.10.05 00:21) [3].
Дело в том, что если что-то сразу сделать public или published, то потом в наследниках скрыть эти свойства или методы уже не удастся.

← →
Джо © (2005-10-20 02:47) [6]

> [4] Prohodil Mimo © (20.10.05 01:27)
> Джо © (20.10.05 0:12) [2]
> Не просто перечислили, а "подняли" уровень видимости до
> published.
>
> А сразу этого сделать нельзя было?

Можно. Но зато если бы ты захотел, например, убрать у своего наследника какое-нибудь свойство из ObjectInspectora - фиг. Нельзя область видимости понизить, можно только повысить или оставить как есть. А так - наследуйся от TCustomXXX и публикуй (или просто делай public) именно те свойства, которые нужны.
В этом плане похожая ситуация с TControl. У него очень много потенциально полезных свойст объявлена в protected. Например, Ctrl3D. Наследовавшись от него, ты сам решаешь нужно ли тебе в твоем конкретном Контролле это свойство или нет, т.е., выводить его в published или оставить в невидимом private.
Что-то я разболтался...

П.С. Я считаю ответ [5] kaif © исчерпывающим, просто вопрос был задан непосредственно мне, поэтому и отвечаю ;)

← →
Юрий Зотов © (2005-10-20 06:28) [7]

> если в TComboBox не произошло никаких изменений, а только перечислили
> свойства

А это разве не изменения?

← →
Prohodil Mimo © (2005-10-21 00:13) [8]

Ну ладно... уговорили :о)

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

> Prohodil Mimo © (21.10.05 00:13) [8]

> Когда изучал как устроен StringGrid, пришлось не мало поскакать от
> одного к другому.

За что (подумав!) стоит стазать "спасибо" этим парням. Разве нет?

:о))))))))))

> Prohodil Mimo © (19.10.05 23:51)
>
> Посмотрел исходники VCL, довольно часто попадаются компоненты,
> типа (TCustomComboBox и TComboBox).
> Зачем нужно было делать TCustomComboBox, если в TComboBox
> не произошло никаких изменений, а только перечислили свойства
> из TCustomComboBox. Почему TCustomComboBox сразу не назвали
> TComboBox?
> И такое бывает не редко.

Это очередной ляп Хайлсберга как архитектора среды, который свалил из Borland в Microsoft, как только была выпущена Delphi3. А дальше уже ничего не оставалось делать, как растить среду на том фундаменте, на котором её ЗАЛОЖИЛИ. Придумывать новую сущность - published Properties было необязательно, достаточно лишь трёх: public, protected и private, что очевидно связано с маркетинговыми соображениями и позиционированием Delphi как среды быстрой разработки кода (RAD).

Во времена последних i486DX4 и первых Pentium производительности и памяти (от 8МБ до 16МБ) настольных машин не хватало на полную интроспекцию бинарного кода библиотечного компонента, взятого из палитры (находится в *.DCU, *.DPL, позднее *.BPL), и динамического построения списка доступных (public) в design-time свойств для последующего отображения их в ObjectInspector. К тому же реализация полноценного two-way-tools визуального дизайнера с редактором кода не представлялась возможной.

Поэтому решили отказаться от полного сканирования секции public и ограничить область доступных свойств, введя ключевое слово published, а заодно хранить инициализированные программистом значения в простых ресурсных файлах (*.DFM) - отдельно от исходного кода приложения (halftwo-way-tools).

Убили сразу двух белок: увеличили быстродействие интроспектора в design-time, но и Хайлсберг был вынужден проектировать библиотеку так, чтобы в палитру могли попасть только те компоненты, которые имеют секцию published - "концевые" компоненты иерархии библиотеки VCL и их потомки, что выше (без published-свойств) - ни-ни (например, TObject на самом верху).

И понеслось...из-за чего вызовы из прикладного кода работают на 2..5% медленнее (так как появились дополнительные VMT "промежуточных" классов). :p

Это лишь гипотезы. ;)

Например, Borland JBuilder на Pentium133 заметно тормозил из-за прямой инроспекции public-свойств компонентов (JavaBeans) в design-time и из-за полного two-way-tools с редактором кода. Поэтому скорость Delphi в те времена была просто песней по сравнению с ним.

Почему так пишут компоненты? Найти похожие ветки