Verwalten von Objekten in einer Container-Klasse

[Luckie]

Auf die Idee bin ich natürlich nicht gekommen. :wall: Dank dir. Ich werde dann heute Abend mal den Artikel und das Tuorial hier überarbeiten und wieder einstellen.

[Khabarakh]

Abgesehen von Deriving or Wrapping hat sich ein ganz allgemeiner Fehler eingeschlichen:

Zitat:

Zitat von Luckie

Delphi-Quellcode:

  if Assigned(Contact) then
    // ...
  else
    raise Exception.Create(rsObjectIsNil);

//...

  Self.Items[Index].Free;
  Self.Items[Index] := nil; // Hmm ;)

[IngoD7]

Zitat:

Zitat von Luckie

Ich habe es jetzt so:

Delphi-Quellcode:

(...)
  TAddressBook = class(TObject)
  private
     FContacts: TContactList;
  public
    constructor Create;
    destructor destroy; override;
    property Contacts: TContactList read FContacts write FContacts;   //<------- write auch?? (IngoD7)
  end;

Frage:
Bist du sicher, dass du da die Referenzierung auf eine andere TContactList-Instanz ermöglichen möchtest?
Die Daten der im Konstruktor erzeugten Instanz von TContactList liegen danach im Nirvana.

[Luckie]

Ups, war pure Gewohnheit.

@Khabarakh: Ich setze dort nur den Zeiger auf nil. Ist zwar an dieser Stelle wohl überflüssig, aber schaden sollte es nicht.

[Khabarakh]

Generell schadet das Nillen nicht, aber wenn du im dadurch aufgerufenen Setter bei nil eine Exceptions wirfst, dann schadet es ;) .

[Luckie]

Delphi-Quellcode:

procedure TContactList.SetItem(Index: Integer; Contact: TContact);
begin
  if Assigned(Contact) then
    FInnerList.Items[Index] := Contact
end;

:zwinker:

[Thorben_K]

Ich hoffe du erlaubst mir die Frage, aber der Sinn von TAdressBock ist mir nicht klar.

Willst du damit nur verhindern das jemand die ContactList verändern kann, oder wie seh ich das?

[Elvis]

Zitat:

Zitat von Khabarakh

Generell schadet das Nillen nicht, aber wenn du im dadurch aufgerufenen Setter bei nil eine Exceptions wirfst, dann schadet es ;) .

Erst wenn du nichts mehr aus deinem Code entfernen kannst bist du fertig damit.
Sinnloses nil-en von Werten, die eh aus dem Scope rennen (weil das Element nicht mehr in der Liste ist!), halte ich für mehr als überflüssig. ;)
Außerdem kannst du eine ObjectList mit OwnsObjects = true benutzen, und du musst dich damit nicht mehr befassen.


btw: Vielleicht sollte Michael den Thread mal auseinanderreisen: In das Tutorial und unser Fachchinesisch als "Diskussion zu ..."

[IngoD7]

Zitat:

Zitat von Thorben_K

Ich hoffe du erlaubst mir die Frage, aber der Sinn von TAdressBock ist mir nicht klar.

Willst du damit nur verhindern das jemand die ContactList verändern kann, oder wie seh ich das?

So, wie TAdressBook da jetzt steht (also nur mit der Eigenschaft Contacts), hat es augenscheinlich keinen besonderen Nutzen. Da könnte man auch gleich eine TContactList instanziieren und verwenden.

Aber vielleicht spielt dieses Adressbuch ja beim Aufschlagen (programmtechnisch: im Konstruktor) ein Liedchen ab. Wer weiß ... ;)
Ein Adressbuch hat ja (später) vielleicht auch noch mehr Eigenschaften, wie z.B. Notizseiten und Registerblätter, etc. pp.

Dass also TAdressBook hier überhaupt - und noch so nackt - steht, dürfte nichts besonderes zu bedeuten haben.

[Luckie]

Zitat:

Zitat von Elvis

Erst wenn du nichts mehr aus deinem Code entfernen kannst bist du fertig damit.

Schönes Zitat. Wuirst du jetzt zum Julius Cäsar der Programmierung: "Bello Programaticus" ;)

Zitat:

Sinnloses nil-en von Werten, die eh aus dem Scope rennen (weil das Element nicht mehr in der Liste ist!), halte ich für mehr als überflüssig. ;)

Gewohnheitssache. Wenn man sich so was einfach mal angewöhnt, kann man es nicht vergessen, wenn man es mal braucht.

Zitat:

Außerdem kannst du eine ObjectList mit OwnsObjects = true benutzen, und du musst dich damit nicht mehr befassen.

Und genau deshalb wollte ich sie in dem Tutorial nicht verwenden.

@Thorben_K: Im Augenblick wäre die Klasse TAddressBook natürlich noch überflüssig. Aber wenn man dann mal ein richtiges Adressbuch schreibt kommen ja noch mehr Dinge hinzu, die man dann dort sinnvoll kapseln kann.