2

カスタム コンポーネントを作成するとき、公開された永続プロパティを実装することがあります。例えば...

type
  TMyComponent = class(TComponent)
  private
    FMyPersistent: TMyPersistent;    
    ...
  public
    ...
  published
    property MyPersistent: TMyPersistent read FMyPersistent write SetMyPersistent;
    ...
  end;

手順SetMyPersistentはまだここにないことに注意してください。ここで次のステップに進みます。このオブジェクトを右クリックし、[カーソル位置でクラスを完了する] (またはShift + Control + C) を選択して、コード補完を呼び出します。このプロパティセッターを自動的に作成すると、割り当てコードが自動的に...

procedure TMyComponent.SetMyPersistent(const Value: TMyPersistent);
begin
  FMyPersistent := Value;
end;

先に進んで、この割り当てを完了してくれたことは素晴らしいことです。しかし、通常の場合、私は常に使用に慣れてきました...

procedure TMyComponent.SetMyPersistent(const Value: TMyPersistent);
begin
  FMyPersistent.Assign(Value);
end;

プロパティがStringやなどの型である場合Integerは、直接代入が適切な方法です。しかし、 の公開されたプロパティを実装する場合、TPersistentを使用する正しい方法ではありませんTPersistent.Assignか?

これら 2 つの割り当てメカニズムを使用する際の本質的な違いは何ですか? 使用するTPersistent.Assignことが適切である場合、コード補完にはわずかな欠陥があります-つまり、それFMyPersistent := Valueが「間違っている」と見なされると仮定します。

4

2 に答える 2

3

コールしAssignます。そのため、最初にプロパティ セッターが必要です。フィールドを直接上書きする場合は、セッターは必要ありません。上書きすると、コンストラクターで作成した元のオブジェクトがリークします。また、オブジェクト インスペクタでプロパティを変更すると、IDE でアクセス違反が発生することもわかります。

コード補完は、作成するすべてのセッターに同じコードを配置します。最終的に値をフィールドに格納する前に追加の作業を行うプロパティの場合、field-storage ステートメントは正しいです。IDE は、あなたが本当に欲しいものを知りません。

于 2013-10-25T01:56:36.933 に答える