Почему я не должен использовать «if Assigned ()» перед доступом к объектам?

Это очень широкий вопрос с разных точек зрения.

Смысл Assigned функции

Большая часть кода в вашем вопросе выдает неверное понимание Assigned функции. Документация утверждает это:

Проверяет нулевой (неназначенный) указатель или процедурную переменную.

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

Назначенный (P) соответствует тесту P <> nil для переменной-указателя и @P <> nil для процедурной переменной.

Assigned возвращает False, если P равно нулю, в противном случае - True.

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

....

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

Значение Assigned отличается для указателя и процедурных переменных. В оставшейся части этого ответа мы рассмотрим только переменные-указатели, так как это контекст вопроса. Обратите внимание, что ссылка на объект реализована как переменная-указатель.

Ключевые моменты, которые следует взять из документации, для переменных-указателей:

1. Assigned эквивалентно тестированию <> nil.
2. Assigned не может определить, является ли указатель или ссылка на объект действительным или нет.

Что это означает в контексте этого вопроса?

if obj<>nil

а также

if Assigned(obj)

полностью взаимозаменяемы.

Тестирование Assigned до вызова Free

Реализация TObject.Free очень особенная.

procedure TObject.Free;
begin
  if Self <> nil then
    Destroy;
end;

Это позволяет вам вызывать Free для ссылки на объект, которая равна nil и это не имеет никакого эффекта. Что бы это ни стоило, я не знаю другого места в RTL/VCL, где бы использовался такой прием.

Причина, по которой вы хотите разрешить вызов Free для ссылки на объект nil связана с тем, как конструкторы и деструкторы работают в Delphi.

Когда в конструкторе возникает исключение, вызывается деструктор. Это сделано для того, чтобы освободить любые ресурсы, которые были выделены в той части конструктора, которая преуспела. Если бы Free не был реализован как есть, то деструкторы должны были бы выглядеть так:

if obj1 <> nil then
  obj1.Free;
if obj2 <> nil then
  obj2.Free;
if obj3 <> nil then
  obj3.Free;
....

Следующая часть головоломки состоит в том, что конструкторы Delphi инициализируют память экземпляра нулями. Это означает, что любые неназначенные ссылочные поля объекта равны nil.

Соберите все это вместе, и код деструктора станет

obj1.Free;
obj2.Free;
obj3.Free;
....

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

Есть один сценарий, в котором вам нужно проверить, назначена ли ссылка в деструкторе. Если вам нужно вызвать какой-либо метод объекта перед его уничтожением, тогда вам следует остерегаться того, что он может быть nil. Таким образом, этот код будет рисковать AV, если он появится в деструкторе:

FSettings.Save;
FSettings.Free;

Вместо этого ты пишешь

if Assigned(FSettings) then
begin
  FSettings.Save;
  FSettings.Free;
end;

Тестирование Assigned вне деструктора

Вы также говорите о написании защитного кода вне деструктора. Например:

constructor TMyObject.Create;
begin
  inherited;
  FSettings := TSettings.Create;
end;

destructor TMyObject.Destroy;
begin
  FSettings.Free;
  inherited;
end;

procedure TMyObject.Update;
begin
  if Assigned(FSettings) then
    FSettings.Update;
end;

В этой ситуации снова нет необходимости тестировать Assigned в TMyObject.Update. Причина в том, что вы просто не можете вызвать TMyObject.Update если конструктор TMyObject успешно. И если конструктор TMyObject успешно, вы точно знаете, что FSettings был назначен. Итак, снова вы делаете свой код гораздо менее читабельным и трудным для поддержки, вводя ложные вызовы в Assigned.

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

constructor TMyObject.Create(UseLogging: Boolean);
begin
  inherited Create;
  if UseLogging then
    FLogger := TLogger.Create;
end;

destructor TMyObject.Destroy;
begin
  FLogger.Free;
  inherited;
end;

procedure TMyObject.FlushLog;
begin
  if Assigned(FLogger) then
    FLogger.Flush;
end;

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

Эта не редкая форма кода делает еще более важным, чтобы вы не использовали ложные вызовы Assigned для не необязательных объектов. Когда вы видите if Assigned(FLogger) в коде, это должно быть четким указанием на то, что класс может нормально работать с FLogger не существует. Если вы распыляете безвозмездные вызовы в Assigned вокруг вашего кода, вы теряете возможность сразу определить, должен ли объект существовать всегда.