Bei Erzeugung einer eigenen Klasse knallts

[Blup]

Verbesserungsvorschläge:
- Ich würde den Constructor zumindest public machen, schließlich ist der Standard-Constructor "create" auch public.
- Zur Verwaltung der einzelnen Tracks bietet sich die TObjectList an.
- Die Tracklist braucht auf jeden Fall einen Destructor, damit die einzelnen Tracks freigegeben werden, bzw. die TObjectList.
- Die einzelnen Property der Tracks in der Tracklist noch einmal zu veröffentlichen ist unnötig umständlich. Besser nur den Track veröffentlichen und beim Track die entsprechenden Property public.

Delphi-Quellcode:

type
  TTrack = class
  strict private
    FAlbum: String;
    FNumber: Integer;
    FTitle: String;
    FInterpret: String;
    FComposer: String;
    FGenre: String;
    FCategory: String;
    FDescription: String;

    FStartTime: Cardinal;
    FLengthInMilliseconds: Cardinal;
    FStreamPath: String;
    FStream: TStream;

    class var FTrackCount: Integer;
  private
    class property TrackCount: Integer read FTrackCount write FTrackCount;
  protected
    procedure SetStream(AStream; TStream);
  public
    constructor Create(Directory: String);

    property Album: String read FAlbum write FAlbum;
    property Number: Integer read FNumber write FNumber;
    property Title: String read FTitle write FTitle;
    property Interpret: String read FInterpret write FInterpret;
    property Composer: String read FComposer write FComposer;
    property Genre: String read FGenre write FGenre;
    property Category: String read FCategory write FCategory;
    property Description: String read FDescription write FDescription;

    property StartTime: Cardinal read FStartTime;
    property LengthInMilliseconds: Cardinal read FLengthInMilliseconds;
    property Stream: TStream read FStream;
    property StreamPath: String read FStreamPath;
  end;

  TTrackList = class
  private
    FTrackList: TObjectList;
    FTemporaryDirectory: String;

    FNumberOfChannels: Cardinal;
    FBitsPerSample: Cardinal;
    FSampleRate: Cardinal;

    procedure AddTrack();
    function GetTrack(TrackNumber: Integer): Track;
  public
    constructor Create(TemporaryDirectory: String);
    destructor Destroy; override; // <- FTrackList freigeben

    property NumberOfChannels: Cardinal read FNumberOfChannels;
    property BitsPerSample: Cardinal read FBitsPerSample;
    property SampleRate: Cardinal read FSampleRate;

    procedure MoveTrack(StartTrackNumber, EndTrackNumber: Integer);
    procedure DeleteTrack(TrackNumber: Integer);

    function GetLastTrackStream(): TStream;
    function GetLengthOfAllTracksInMilliseconds(): Cardinal;

    property Track[TrackNumber: Integer]: TTrack read GetTrack; default;
  end;


// Zugriff auf einzelne Property des Track
  TrackList[TrackNumber].Album

[hadschi92]

Blup, deine Anregungen sind gut. Ein paar Fragen habe ich noch:

Wieso muss der Konstruktor nicht mit mit override überschrieben werden? Gibt es keinen Standardkonstruktor? Dass ein Override beim Destruktor dazu muss ist mir inzwischen klar geworden, ich habe mich immer gewundert, warum mein Destruktor nie aufgerufen wird...

Delphi-Quellcode:

type
  TTrack = class
  strict private
    FAlbum: String;

  public
    constructor Create(Directory: String);

    property Album: String read FAlbum write FAlbum;

Hier kann ich in der Funktion Create jetzt entweder auf FAlbum oder Album zugreifen und lande beides mal auf der gleichen Variable. Was ist sauberer? Innerhalb einer Klassenmethode immer auf die Private Variablen zugreifen und nur wenn man von einer anderen Klasse kommt auf die Public Variablen zugreifen? Oder immer auf die Public Variablen zugreifen?

[Medium]

Das kommt darauf an. Wenn der Setter/Getter einer Property mehr macht als nur lesen/schreiben des Feldes, kann es mal nötig sein diese zusätzlichen Dinge auch in der Klasse selbst mit auszulösen, an anderen Stellen in der Klasse wäre dies aber ggf. auch völlig verkehrt. Da eine generelle Aussage zu machen traue ich mich nicht.

In deinem konkreten Fall (also reines Weiterreichen der Zugriffe an das private Feld) würde ich tendenziell eher die Property nehmen, damit wenn später doch mal Getter/Setter dazu kommen, diese auch benutzt werden. Die Spezialfälle in denen man sie gezielt umgehen muss dürften weniger wahrscheinlich sein, so das dann hoffentlich weniger zu ändern ist im restlichen Code. Geschwindigkeitseinbußen gibt es dabei nicht, da Delphi bei dieser Art der Property (so weit ich weiss) im Kompilat das gleiche produziert wie bei einem direkten Zugriff auf das private Feld.