А зачм в Delphi нужна директива abstract? В чём её прелесть? Почему не сделать виртуальный метод с пустым телом в базовом классе, как это в TDataLink сделано?

> Ega23 ©   (13.05.08 20:43)

С..с..с..с..! - однозначно военная тайна.

Например, чтобы ОБЯЗАТЬ потомков перекрывать этот метод (потому что с пустым методом класс неработоспособен), а компилятор получил возможность ругаться на неперекрытый метод.

> С..с..с..с..! - однозначно военная тайна.


Не, серьёзно. Абстрактный класс в Delphi оздать можно. При переопределении абстрактного метода по Ctrl + Shift + C эта сволочь inherited автоматом ставит и если забудешь убрать - abstract error
Одни расстройства...

> Например, чтобы ОБЯЗАТЬ потомков перекрывать этот метод
> (потому что с пустым методом класс неработоспособен), а
> компилятор получил возможность ругаться на неперекрытый
> метод.


А зачем? Юр, ну вот реальный пример приведи? Я серьёзно не понимаю, в чём такая офигенная польза.

> [4] Ega23 ©   (13.05.08 20:50)
> А зачем? Юр, ну вот реальный пример приведи? Я серьёзно
> не понимаю, в чём такая офигенная польза.

Ну, например, разработал я базовый интерфейс (абстрактный класс) и отдал его сотруднику, чтобы плодил он потомков по образу и подобию. Если не реализует какой-то из методов, коий обязательно должен быть реализован — компилятор ему быстро об этом напомнит :) Примерно так.

> Ega23 ©   (13.05.08 20:50) [4]

реальный? :) обостренная болезнь создать экземпляр TStrings :)
задумайся

> Ну, например, разработал я базовый интерфейс (абстрактный
> класс) и отдал его сотруднику, чтобы плодил он потомков
> по образу и подобию. Если не реализует какой-то из методов,
>  коий обязательно должен быть реализован — компилятор ему
> быстро об этом напомнит :) Примерно так.


Тогда уж проще действительно интерфейс объявить, без реализации его методов ты и не скомпилируешься...

> реальный? :) обостренная болезнь создать экземпляр TStrings :)
> задумайся


А чё задумываться? Я же говорю, я бы не задавал вопросов, если бы в Delphi отсутствовала возможность создания абстрактного класса. Но она же есть! И как раз из-за неё все эти болезни по созданию TStrings

> Ega23 ©   (13.05.08 20:50) [4]


Если метод Draw абстрактный и программист забыл его перекрыть, то он получит вразумительный Abstract Error.

Если же метод Draw сделать пустым и программист забудет его перекрыть, то он будет ломать голову, почему это у него ничего не рисуется.

Это простой пример. Программист увидит, что ничего не рисуется и быстро поймет в чем дело. Но что было бы, если бы метод выполнял НЕвизуальную работу? Это ж еще обнаружить надо, что она не выполняется.

> [7] Ega23 ©   (13.05.08 20:58)
> Тогда уж проще действительно интерфейс объявить, без реализации
> его методов ты и не скомпилируешься...

Проще или нет — это только от задачи зависит. Вот (несколько надуманный) пример:



Здесь в базовом классе уже заложена некая базовая функциональность. Потомки обязаны реализовать некоторые специфичные методы (в данном случае GetSource). Если таковых методов немало — то очень удобно, что компилятор сам проконтролирует их реализацию.

> Ega23 ©   (13.05.08 20:58) [7]

> Тогда уж проще действительно интерфейс объявить, без реализации
> его методов ты и не скомпилируешься...

1. Но тогда придется реализовывать ВСЕ, а не один метод. Зачем?

2. Абстрактные методы в Delphi появились раньше интерфейсов.

> Ega23 ©   (13.05.08 21:00) [8]

Ладно, по аналогии с Юрием

TCommandClass=Class of TCommand;
TCommand=Class
Public
 Constructor... ; Virtual;
 Procedure Execute; Virtual; Abstract;

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

ну вот уже и про ТStrings сказали :)


> Почему не сделать виртуальный метод с пустым телом в базовом
> классе


Это хорошо, если ничего не рисует, это не страшно. Гораздо хуже, если ничего не считает :) Например долгов...

Товарищ. > Ega23 ©  утверждал, что если бы этого метода небыло, то и траблов бы небыло, следовательно
> Если метод Draw абстрактный и программист забыл его перекрыть, то он получит вразумительный Abstract Error.

> Если же метод Draw сделать пустым и программист забудет его перекрыть, то он будет ломать голову, почему это у него ничего не рисуется.

- несуществующие методы выполняться не могут.
До сих пор так и не нашел ни одного преимущества перед классами. классы это зло!

А еще - "Мартышка и очки".

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

То есть, это была бы ошибка компиляции, а не исполнения.

а если метод вернуть что-то должен, int Count, например? что возвращать? 0? -1?
если объект? null? инстанс с дефолтным конструктором?
а если надо вернуть другой абстрактный класс или интерфейс, то создаём первый попавшийся - и в путь?

за null в не внутренних методах и методах типа T Find(id) бью по рукам (обоснованные исключения, конечно, возможны)

есть такое чудесное правило - "не умеешь? не берись", так и тут.
если без понятия, что делать в методе - честно признайся в этом, кинь исключение
а abstact - это по сути то же исключение, только на уровне компиляции

пс. простите за до-диезность =)

> Пробегал2...   (13.05.08 22:01) [16]

На этапе компиляции выдается предупреждение, что нормально. Поскольку если абстрактный метод реально кодом не юзается, то и потомков плодить ни к чему.

> Слоник ©   (13.05.08 22:03) [17]

Ниасилил. Моя си-бемольность не догоняет.

Юрий Зотов, на малую терцию выше берите ;)