AfterConstruction, BeforeDestruction

[Sibedir]

При создании нового класса обычно переопределяют конструктор и диструктов (ну или Free). По крайней мере нас так учили. Там мы инициализируем и обнуляем соответственно поля объекта. Но в классе TObject определены две процедуры

    procedure AfterConstruction; virtual;
    procedure BeforeDestruction; virtual;

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

Дополнительное замечание:
На использование AfterConstruction натолкнула такая ситуация.
Создаю свой класс исключения. Но после его создания мне нужно выполнить некоторые действия. Если написать:

constructor ESib.Create(const Msg: string);
begin
  inherited Create;
  <мои действия>
end;

, то при вызове исключения через, скажем, CreateFmt, <мои действия> не произведутся. А переопределять 12 конструкторов меня не вставляет.

[Аватар]

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

Может и так. А если какие-то не предусмотренные в исходном классе параметры передать конструктору? Без переопределения конструктора наверно слабо

[_-Re@l-_]

А переопределять 12 конструкторов меня не вставляет.

Хех, меня бы тоже не вставило.

, то при вызове исключения через, скажем, CreateFmt, <мои действия> не произведутся.

Так делайте вот так:

constructor ESib.Create(const Msg: string);

begin

  <мои действия>

  inherited Create;

end;

[Аватар]

Так делайте вот так:

constructor ESib.Create(const Msg: string);
begin
  <мои действия>
  inherited Create;
end;

Обычно <мои действия> связаны с объектами создаваемого компонента, поэтому чаще всего такой фокус не пройдет

[evg_m]

Обычно <мои действия> связаны с объектами создаваемого компонента, поэтому чаще всего такой фокус не пройдет

constructor ESib.Create(const Msg: string);
begin
  inherited Create;
 // Здесь поля уже есть и с ними можно работать
  <мои действия>.
end;

[Пепел Феникса]

На использование AfterConstruction натолкнула такая ситуация.

правильно мыслите, только на всяк inherited всетаки надо б вызывать.

они в общем то для подобных случаев и нужны.

в Делфи например так реализован класс RefObject(или как то так)

[Sibedir]

2 Пепел Феникса
А что за RefObject?

2 All
<мои действия> связаны не с полями объекта. Там исключение регистрируется в специальном списке.

Вообще, ощущение такое, что AfterConstruction ввели, для устронения косяков своих же программистов. Ну не логичнее было бы иметь всегда один конструктор, а при необходимости сделать

class function Exception.CreateFmt(const Msg: string; const Args: array of const): Exception;
begin
  Result := Create (Format(Msg, Args));
end;

а Create при этом сделать виртуальным.

[GunSmoker]

Create и AfterConstruction введены для разных моделей инициацизации ресурса. Вот и всё.

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

Как пример - предлагаю посмотреть на реализацию TThread или TCustomForm. Очень чёткая и доступная логика.