[Delphi] Klasa z obiektem

Witam mam pewien problem z klasami <ort>przejżałem </ort>dużo artykułów o nich i wszędzie jest to jakoś potraktowane po macoszemu, ale do rzeczy
Mam 2 klasy

TFirma = class
...
ListaPracownikow:TListaPracownikow
...
end;

oraz

TListaPracownikow = class (TList)
...
constructor Create(parent :TFirma);
...
end;

Podstawowy problem to taki, że klasa TFirma nie wie co to TListaPracownikow i odwrotnie można to jej jakoś zaznaczyć bez zmiany kolejności?
Poza tym w klasie TListaPracownikow przydało by mi sie pole "parent" po którym chciałbym się w razie potrzeby dostać o poziom wyżej czyli do obiektu klasy TFirma czy coś takiego jak napisałem wyżej ma sens?

Możecie polecić jeszcze jakiś projekt np. na SourceForge w delphi który byłby oparty na klasach, ale taki z którego można by czerpać wzorce i zobaczyć jak to w praktyce dobrze wygląda bo w kursach zawsze są jakieś dziwne przykłady które kupy nie trzymają.

pozdrawiam

TListaPracownikow = class;

TFirma = class
  ...
  ListaPracownikow:TListaPracownikow
  ...
end;

oraz

TListaPracownikow = class (TList)
  ...
  constructor Create(parent :TFirma);
  ...
end;

co nie zmienia faktu, że taka konstrukcja wskazuje na zły projekt

według ciebie nie powinno się w jednym obiekcie "trzymać" referencji do innego obiektu czy co dokładniej miałeś na myśli? sugerujesz żeby tych klas <ort>w ogóle </ort>nie wiącać? nie wiem co tu może być złego każda firma ma tylko 1 Listę pracowników jest ona tworzona podczas tworzenia firmy i zwalniana też jak jest zwalniana firma - coś w stylu relacji 1 do 1

jeśli ListaPracowników potrzebuje mieć dostęp do Firmy to tu jest błąd. Owszem są sytuacje, gdzie takie konstrukcje mają swoje uzasadnienie ale są to dość specyficzne przypadki.

Ok będę unikał tego choć tu wydaje mi się to zasadne bo po co mam tworzyć np. 20 firm i 20 list a później jeszcze myśleć jak się wygodnie do tego odwoływać.

W każdym razie dzięki za kodzik tego było mi potrzeba

ale skąd gdzie się chcesz odwoływać??? Przecież jak chcesz mieć 20 RÓŻNYCH firm to każda musi mieć SWOJĄ listę pracowników. Jedyne o czym cały czas mówię to dlaczego lista pracowników musi wiedzieć w jakiej jest firmie. Może napisz po co Ci w liście pracowników parent, do czego zamierzasz go wykorzystać

Dajmy na to, że potrzebuje zaczerpnąć informacji o firmie np. adres firmy do której należy pracownik.
Teraz wystarczy napisać w byle jakiej metodzie listy

ShowMessage('pracuje w firmie' + parent.adres);

to o wiele szybsze niż szukania znów gdzie jest firma od tej listy mam nadzieje że rozumiesz o co mi chodzi

tylko, że klasa pracownik nie powinna mieć interakcji z GUI. Takie rzeczy jak wyświetlanie do jakiej formy należy dany pracownik powinno leżeć w gestii klasy odpowiedzialnej za interakcję z userem a nie w samej klasie pracownik

Użyłem tu uproszczenia z tym ShowMessage
klasa Firma ma w sobie kilka tablic, które są uaktualniane od czasu do czasu i mając akurat danego pracownika na celowniku chcę pobrać dane z firmy, gdy wywołam pewną metodę na pracowniku, dlatego taki skrót z powrotem do firmy w metodzie listy jest mi na rękę.
Zostawię to jak jest bo kod jest i tak dla mnie i zadowala mnie to rozwiązanie.
Tymczasem pobiorę sobie kody źródłowe jakichś większych projektów w delphi i pooglądam jak to wszystko w praktyce wygląda bo jak na razie nie widzę zbyt dużych zalet programowania oop po suchej teorii z kursów

Klasy podrzedne na dłuższą metę wygodniej ograniczyć tylko do trzymania danych, potem masz wszystkie metody w głównej klasie przez co chociażby nie trzeba skrobać a.b.c.d.e.f.Foo(); - zarządzanie danymi zostaw głównej

type
  Thostage=class
    name:string;
  end;
  Tterrorist=class
    bombsize:word;
    nick:string;
  end;
  TtetroristGroup=class
    leader:string;
    Hostages:TList;
    Terrorists:TList;
    procedure SucideAtack(name:string;target:object);
    procedure Kill(name:string);
    function SetFree(name:string):Thostage;
    procedure TransferCapitalisticPigsToAnotherCell(TterroristGroup);
    procedure Detonate();
  end;

muhmuhmuh napisał(a)

Klasy podrzedne na dłuższą metę wygodniej ograniczyć tylko do trzymania danych, potem masz wszystkie metody w głównej klasie przez co chociażby nie trzeba skrobać a.b.c.d.e.f.Foo(); - zarządzanie danymi zostaw głównej
chyba sobie jaja robisz