Стиль: Вызов виртуальных методов из деструкторов

← →
Ученик (2002-10-31 09:40) [40]

>Юрий Зотов © (31.10.02 09:04)
Вы согласны с тем, что человек не в состоянии запомнить все особенности написанных им классов (например, где он вызывал inherited Create(Destroy), а где нет) ?

← →
Юрий Зотов (2002-10-31 09:51) [41]

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

А Вы согласны с тем, что:

1. Думать нужно всегда.
2. Механическое следование любому стилю - это плохой стиль.

← →
Ученик (2002-10-31 10:00) [42]

>Юрий Зотов © (31.10.02 09:51)
"...который стабильно работает и без всяких запоминаний..."
1. Согласен
2. Частично, например, пока в этом нет необходимости, никогда не задумываюсь, что делает (или что будет делать) inherited Destroy, inherited Create, поэтому можно сказать, что вызываю их механически - плохой стиль - может быть, а может быть Delphi1 - Delphi2 - Delphi3 - Delphi4 - Delphi5 - Delphi6 - Delphi 7

← →
Igorek (2002-10-31 10:33) [43]

> Юрий Зотов © (31.10.02 09:04)

Я думаю, это уже полухакерские методы - приводить тип и пользоваться тем фактом, что у поля оказывается одинаковое смещение относительно начала обьекта.
Сам класс TSomeClass недостаточно обеспечивает такого рода использование. Вариантов масса, как всегда. Например сделать виртуальную функцию (как CreateParams для контролов) c var параметром. Передавать в нее можно как раз FStrings. И если пользователь хочет создавать для этого поля обьект другого класса, то он ее перегружает, создает свой обьект и присваивает параметру.
Т.е. в данной формулировке задача не имеет корректного и красивого решения (imho)

← →
Юрий Зотов (2002-10-31 10:36) [44]

> Delphi1 - Delphi2 - Delphi3 - Delphi4 - Delphi5 - Delphi6 -
> Delphi 7

Есть ВОЗМОЖНОСТЬ (внесения изменений), а есть ее ВЕРОЯТНОСТЬ.

Вы представляете, что может произойти, если в очередной версии Borland перекроит базовые классы? Тем более, TObject и TPersistent, от которых чуть ли не вся VCL и растет. Произойдет что-то типа катастрофы, причем почти гарантированно.

Так вот - какова вероятность того, что Borland пойдет на такой шаг? Тем более, что он запросто может отразиться на популярности Delphi - а значит, и на доходах фирмы.

Мизерная. Практически нулевая.

Стоит ли закладываться на некую мифическую вероятность и ради нее жертововать реальной (!!!) эффективностью своих программ?

В D6 Borland перекроила юниты. Это была вынужденная мера, связанная с обеспечением кроссплатформенности. Один из итогов - своей цели они достигли (что весьма перспективно в смысле тех же доходов). Другой итог - даже у нас, где Delphi на 90% халявная, очень многие до сих пор не хотят уходить с D5. Потому что не хотят перекапывать свои исходники.

Что уж тогда говорить о людях, которые платят за инструмент свои кровные? Они тем более не хотят головной боли за свои же деньги.

Когда Вы врезаете новый замок, Вы делаете запасные ключи. На случай потери основных. Но Вы не делаете их в 10 экземплярах на случай 10-кратной потери, верно? Хотя такая вероятность тоже существует, но Вы понимаете, что она весьма мала и руководствуетесь здравым смыслом.

Почему же в программировании должно быть иначе?

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

← →
Igorek (2002-10-31 10:52) [45]

> Юрий Зотов © (31.10.02 10:36)
> Позиции ясны и в главном (что всегда надо думать) мы сошлись.

Вот тут я, простите, в корне не согласен. Это как прокладывать асфальт наново каждый раз в том направлении, куда едем. Программист должен по возможности думать ОДИН раз над ОДНОЙ задачей.

← →
Юрий Зотов (2002-10-31 11:52) [46]

> Igorek © (31.10.02 10:33)

> Я думаю, это уже полухакерские методы - приводить тип и
> пользоваться тем фактом, что у поля оказывается одинаковое
> смещение относительно начала обьекта.

Полностью согласен. Поэтому я использую более универсальные и более надежные способы - но они тоже не требуют вызова inherited. Вот о чем в данном случае идет речь, а не о том или ином способе подмены класса.

> Сам класс TSomeClass недостаточно обеспечивает такого рода
> использование.

Естественно. Он же не нами писан и его автор не рассчитывал на такое наследование. Зато он написал какой-то очень хитрый метод SomeProc, ради которого нам и нужна вся эта бодяга. Этот пример я придумал из головы, но такая же ситуация реально существует, например, в TListView. Для Items там предусмотрена CreateListItem, но попробуйте вживить в него свои колонки. И это далеко не только в TListView.

> Т.е. в данной формулировке задача не имеет корректного и
> красивого решения

Мне самому не нравятся задачи подобного рода, но иногда приходится решать и такие. Что делать...

> Igorek © (31.10.02 10:52)

> Это как прокладывать асфальт наново каждый раз в том
> направлении, куда едем.

Между прочим, в Германии таким способом ремонтируют дороги - сначала прокладывают объездную (капитальную, не грунтовку), а потом делают старую. Вероятно, это одна из причин того, что с дорожной сетью там совсем неплохо. При следующем ремонте строить уже ничего не надо, а вместо одной плохой дороги получаем две хороших.

> Программист должен по возможности думать ОДИН раз над ОДНОЙ
> задачей.

Лучше не над одной, а над ЭТОЙ и БУДУЩИМИ. Одновременно. Этим и отличается написание ядра (классов, библиотек...) от прикладного программирования. Мышление другое, понимаете? Как в Германии.

Выше я привел пример конструктора, который, с одной стороны, потом не придется переделывать (с вероятностью 5 девяток) и который, с другой стороны, не заставит меня потом думать над повышением скорострельности программы. Ни текущей, ни последующих. Вот это и называется - думать ОДИН раз. Как в Германии.

Уф-ф-ф. Устал я, ребята, от этих споров. Поступайте, как знаете. Всем до свидания.

← →
down (2002-10-31 12:15) [47]

> Полностью согласен. Поэтому я использую более универсальные
> и более надежные способы - но они тоже не требуют вызова
> inherited. Вот о чем в данном случае идет речь, а не о том
> или ином способе подмены класса.

Юрий, а какие еще методы есть (в случае готового класса, исходники которого править нельзя)?

← →
Юрий Зотов (2002-10-31 12:51) [48]

Например, WriteProcessMemory(..., @Strings,...), или что-то типа этого:

var
PStrings: ^TStrings;
begin
PStrings := @Strings;
PStrings^ := TMyStringList.Create
end;

Это тоже не на 100% универсально (проходит для полей с прямым доступом по чтению), но уже не зависит ни от каких смещений. А поэтому годится для любого по порядку поля и не зависит от версии предка.

← →
down (2002-10-31 12:59) [49]

Спасибо!

Стиль: Вызов виртуальных методов из деструкторов Найти похожие ветки