AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Thema durchsuchen
Ansicht
Themen-Optionen

Komponente ableiten

Ein Thema von hansklok · begonnen am 30. Aug 2010 · letzter Beitrag vom 1. Jan 2011
Antwort Antwort
Seite 3 von 3     123   
r2c2

Registriert seit: 9. Mai 2005
Ort: Nordbaden
925 Beiträge
 
#21

AW: Komponente ableiten

  Alt 5. Sep 2010, 11:40
Ich habe einen Entwurf für eine Event-Oberklasse gemacht, von ihm sind dann neue Objekttypen (z.B. Scheidung, Hochzeit etc.) abgeleitet.
Aus welchem Grund? Tu sowas nur, wenn du einen Vorteil daraus hast. Das macht die Sache erstmal deutlich komplizierter. Damit du das wirklich nutzen kannst, müsstest du Polymorphie einsetzen können und da sehe ich momentan keine sinnvolle Möglichkeit. Modelliere wirklich nur das, was du auch brauchst. Ansonsten machst du dir nur das Leben schwer: http://de.wikipedia.org/wiki/KISS-Prinzip

Weitere Daten kannst du - wenn nötig - entweder zu TPerson (oder andere Klassen) packen oder in ne generische Notizklasse auslagern. Du brauchst nicht zu allem, was dir einfällt, ne eigene Klasse.

Alles weitere in der Antwort auf deine Mail.

Zitat:
Zitat:
Kennst du Scrollbars?
Ja die kenne ich. Natürlich kann man später auch alle Generationen darstellen, mal sehen wann wir an die stelle kommen. Ursprünglich dachte ich an die Übersichtlichkeit. lass uns mal gucken, wies aussieht, wenn wir das Problem gelöst haben.
Ja, das sehen wir dann, wenn wir uns der grafischen Darstellung widmen.

mfg

Christian
Kaum macht man's richtig, schon klappts!
  Mit Zitat antworten Zitat
hansklok

Registriert seit: 14. Apr 2004
Ort: Karlsruhe
318 Beiträge
 
Delphi 2010 Architect
 
#22

AW: Komponente ableiten

  Alt 7. Sep 2010, 19:08
Aus welchem Grund? Tu sowas nur, wenn du einen Vorteil daraus hast. Das macht die Sache erstmal deutlich komplizierter. Damit du das wirklich nutzen kannst, müsstest du Polymorphie einsetzen können und da sehe ich momentan keine sinnvolle Möglichkeit. Modelliere wirklich nur das, was du auch brauchst. Ansonsten machst du dir nur das Leben schwer: http://de.wikipedia.org/wiki/KISS-Prinzip

Weitere Daten kannst du - wenn nötig - entweder zu TPerson (oder andere Klassen) packen oder in ne generische Notizklasse auslagern. Du brauchst nicht zu allem, was dir einfällt, ne eigene Klasse.
Das verstehe ich, nur ich hatte mir folgendes überlegt (wieder in Hinblick auf den Standard):

Eine Geburt oder eine Hochzeit sind genauso Ereignisse wie eine Taufe oder eine Scheidung. Nicht immer gibt es eindeutige Belege über den Zeitpunkt eines Ereignisses, deshalb können auch Zeitspannen (z.B. zwischen dem 31.01.2009 und 03.04.2009) angegeben werden. Alle diese exemplarischen Ereignistypen haben dieselben Standardeigenschaften (z.B. Datum, Ort). Deshalb habe ich neue Klassen von TEvent abgeleitet und beispielsweise bei TMarriage noch den Taufpaten als Eigenschaft hinzugefügt, verstehst du?

Ein Umzug, also ein Wohnortwechsel ist genauso ein Ereignis wie z.B. eine Volkszählung. Das war mein Hintergrundgedanke bei der ganzen Sache.

Erkläre mir bitte nochmal deine Alternative genauer!

HG hansklok
  Mit Zitat antworten Zitat
r2c2

Registriert seit: 9. Mai 2005
Ort: Nordbaden
925 Beiträge
 
#23

AW: Komponente ableiten

  Alt 7. Sep 2010, 22:13
Eine Geburt oder eine Hochzeit sind genauso Ereignisse wie eine Taufe oder eine Scheidung.
Das ist klar und unproblematisch. Nur heißt das nicht, dass man das auch modellieren muss. Jede Person ist ein Lebewesen. Außerdem gibt es unterschiedliche Personen: Männer und Frauen. Achso und Kinder gibt es auch noch. Also Mädchen und Jungen. ... Trotzdem wirst du in deinem Programm keine TLivingBeing, TMan, TWoman, TGorl und TBoy finden. UNd TNose, TLeftEye und TRightEye auch nicht. OK, das sind jetzt Extrembeispiele. Was ich damit sagen will: Nur die Tatsache, dass es logisch gesehen diese Klassifizierung gibt, impliziert noch lange nicht, dass das auch so modelliert werden muss. Jede zusätzliche Klasse bringt zusätzliche Komplexität.

Zitat:
Nicht immer gibt es eindeutige Belege über den Zeitpunkt eines Ereignisses, deshalb können auch Zeitspannen (z.B. zwischen dem 31.01.2009 und 03.04.2009) angegeben werden.
Das ist auch unstrittig. Deshalb gibt es TVagueDate.

Zitat:
Alle diese exemplarischen Ereignistypen haben dieselben Standardeigenschaften (z.B. Datum, Ort). Deshalb habe ich neue Klassen von TEvent abgeleitet und beispielsweise bei TMarriage noch den Taufpaten als Eigenschaft hinzugefügt, verstehst du?

Ein Umzug, also ein Wohnortwechsel ist genauso ein Ereignis wie z.B. eine Volkszählung. Das war mein Hintergrundgedanke bei der ganzen Sache.
Dein Gedanke ist mir klar. Er resultiert meiner Meinung nach aus der typischen Überbewertung der Vererbung.

Wenn man anfängt, OO zu lernen, bleibt einem wohl aus irgendwelchen Gründen die Vererbung besonders gut im Gedächtnis. Der Vorteil erscheint augenblicklich klar: Gleiche Eigenschaften und Methoden werden in Basisklassen definiert und an die Kindklassen vererbt. So muss man das gleiche Zeug nicht mehrmals schreiben. Der Punkt ist: Eigentlich ist Vererbung, genauer: Generalisierung/Spezialisierung viel mehr. Ich hab jetzt nicht die Zeit, das vollständig zu erläutern, aber um mal einen Eindruck zu geben: Der eigentlich Punkt ist, dass man mit den Kindklassen genauso umgehen kann wie mit der Basisklasse. Das werden wir uns wohl später bei der Datenspeicherung zunutze machen [1]: Wir leiten alle zu speichernden Klassen von ner gemeinsamen Basisklasse ab und schreiben Code, der uns erlaubt ein beliebiges Objekt dieser Klasse zu speichern. Wir machen uns also ne Liste mit allen Elementen, die gespeichert werden sollen. Unser Code zum Speichern wird nun die liste in ner Schleife durchgehen und je eine Methode (save) zum Speichern aufrufen.
Delphi-Quellcode:
// Pseudocode
for elem in AllElements do
begin
  elem.save;
end;
Diese vier Zeilen werden es wohl letztendlich im Grunde genommen sein. elem kann eine TPerson sein. Oder ein TPartnership oder ein TAdoption. Egal. Der Code behandelt alle gleich. Es wird auch keine explizite Unterscheidung gemacht "if elem is TPerson then". Das alles passiert - wenn man richtig macht - automatisch durch Vererbung und Polymorphie, d.h. durch dynamische Bindung.

Jetzt meine Frage: Wo wirst du im Code eine Variable als TEvent und nicht als TBirth deklarieren? Wo? Nirgends, denn überall ist der Unterschied zwischen TBirth und TMarriage signifikant. Das sollte schonmal ein Alarmsignal sein. Wenn du einen Typen definierst, den du nie benutzt, ist zwar nicht zwangsläufig, aber doch vermutlich was faul.

Zweiter Punkt: Ist TMarriage nun ein TEvent oder ein TPartnership? Aus gutem Grund kann es nicht beides sein.

Dritter Punkt: Leere Klassen. Du wirst dadurch Klassen haben, die ganz oder fast leer sind. Dem Tod kannst du maximal noch ne Ursache zuweisen, aber essenziell wird das Ding leer sein. TDeath tut nichts anderes als TEvent, es verhält sich mangels Methoden sogar überhaupt nicht. Auch das ist wieder so etwas, wo die Alarmglocken läuten sollten. Das *kann* OK sein. Ist aber oft ein Zeichen für falsches Vorgehen. Oben hab ich irgendwo "OOD and Coffee" verlinkt. Lies das mal. Robert C. Martin beschreibt da wirklich gut, was falsche Abstraktionen sind.

Was ist also die Alternative?
- TPerson hat ein DateOfBirth: TVagueDate
- Und ein DateOfDeath: TVagueDate.
- Wenn du unbedingt noch die Todesursache haben willst, hat TPerson eben auch noch ein CauseOfDeath: string.
- Ansonsten kann die Todesursache, sofern sie mal ausnahmsweise von Bedeutung ist, ja auch als Notiz hinzugefügt werden. Wenn du in ner späteren Version n Feature "Die häufigsten Todesursachen" einbauen willst, kannst du immer noch das CauseOfDeath-Feld einführen. Bis dahin reicht IMHO die Notiz.
==> So wird ein Programm bedeutend einfacher. Wenn du das dann mal implementierst, wirst du merken, dass es auch so schon kompliziert genug ist. Allein schon das freigeben wird dich vermutlich ein paar Stunden kosten, bis dus einigermaßen fehlerfrei implementiert hast. Je nachdem, wie viel ich dir dabei helfe. Denke also nicht, dass du nicht auf Einfachheit achten müsstest. Das, was du vor hast, ist kein kleines Programm mehr.

[1] Achtung! Das ist noch nicht durchdacht. Bisher nur meine vage Vorstellung von dem, was wir letztendlich tun werden. Das muss ich mir später mal genauer durch den Kopf gehen lassen.

mfg

Christian
Kaum macht man's richtig, schon klappts!
  Mit Zitat antworten Zitat
hansklok

Registriert seit: 14. Apr 2004
Ort: Karlsruhe
318 Beiträge
 
Delphi 2010 Architect
 
#24

AW: Komponente ableiten

  Alt 1. Jan 2011, 23:53
Lange war es still, nun bin ich einen Schritt weiter.

Ich habe folgendes Problem und komme nicht weiter:

Im Stammbaum (TFamilyTree ) werden 15 (zunächst, für die Frage nicht weiter wichtig) grafische "Personen" angelegt. Diese sind von der Klasse TTreePerson . Wird im TFamilyTree auf eine TTreePerson einmal geklickt, so soll diese den Focus erhalten (fSelected = True ). Alle anderen 15 Personen sollen im Gegenzug fSelected = False erhalten. Wird eine Person doppelgeklickt, so soll diese im Stammbaum an Position 1 der fTreePerson rutschen und fSelected = True erhalten, dementsprechend aktualisieren sich alle nachfolgenden Generationen aufgrund des neuen Probanden. Genauso verhält es sich mit dem MouseOver. Ich habe keine Ahnung, wie ich das anstellen soll, da sich ja die Personen innerhalb der Komponente "TFamilyTree" befinden.

Hat mich jemand verstanden und kann mir eventuell bitte helfen?

Danke und HG hansklok


Delphi-Quellcode:
unit uGenealogyFamilyTree;
{$mode objfpc}{$H+}

interface

uses
  Classes, Controls, Graphics, SysUtils, uGenealogyFile;

const
  ControlCol = $0099887F;
  LineCol = $00E2E2E2;

  PersBorderColor = $00606060;
  PersHoverCol = $00746155;

  NormalPersonColStart = $00F2F2F3;
  NormalPersonColEnd = $00C5C5C5;
  NormalPersonFontCol = clBlack;

  NormalPersonHoverColorStart = $00F5F1EE;
  NormalPersonHoverColorEnd = $00E0CEC3;

  SelectedPersonColStart = $00D3C3B3;
  SelectedPersonColEnd = $00B39B83;
  SelectedPersonFontCol = clWhite;

  PersonWidth = 210;
  PersonHeight = 60;

type
  TTreePerson = class(TObject)
    private
      fName: String;
      fSelected,
      fMouseOver: Boolean;
    public
      property Name: String read fName write fName;
      property Selected: Boolean read fSelected write fSelected;
      property MouseOver: Boolean read fMouseOver write fMouseOver;

      procedure Draw(AName: String; ACanvas: TCanvas; ATop, ALeft: Integer);
  end;

  TFamilyTree = class(TCustomControl)
    private
      fGeneration,
      fProband, // erste Person eines Stammbaums
      fSelectedPerson: Integer; // ausgewählte Person
      fGenealogyFile: TGenealogyFile;
      fTreePerson: array[1..15] of TTreePerson; // erstmal werden nur 15 dargestellt
    public
      constructor Create(AOwner: TComponent);
      destructor Destroy;

      property Generation: Integer read fGeneration write fGeneration;
      property Proband: Integer read fproband write fProband;
      property SelectedPerson: Integer read fSelectedPerson write fSelectedPerson;
      property GenealogyFile: TGenealogyFile read fGenealogyFile write fGenealogyFile;

      procedure Paint; override;
  end;

implementation

var
  i: Integer;
  PersonRect, PersonOverRect: TRect;
  Style: TTextStyle;

procedure TTreePerson.Draw(AName: String; ACanvas: TCanvas; ATop, ALeft: Integer);
begin
  ACanvas.Pen.Width:= 1;
  ACanvas.Pen.Color:= PersBorderColor;
  ACanvas.Font.Size:= 10;
  Style.Layout:= tlCenter;
  Style.Alignment:= taCenter;
  Style.SystemFont:= False;

  PersonRect:= Rect(ATop, ALeft, PersonWidth, PersonHeight);
  PersonOverRect:= Rect(ATop-5, ALeft-5, PersonWidth+5, PersonHeight+60);

  if fSelected and fMouseOver then
     begin
       ACanvas.Brush.Style:= bsSolid;
       ACanvas.Pen.Width:= 0;
       ACanvas.Brush.Color:= PersHoverCol;
       ACanvas.RoundRect(PersonOverRect, 5, 5);
       ACanvas.GradientFill(PersonRect, SelectedPersonColStart, SelectedPersonColEnd, gdVertical);
       ACanvas.Font.Color:= SelectedPersonFontCol;
     end
  else
  if not fSelected and fMouseOver then
     begin
       ACanvas.Brush.Style:= bsSolid;
       ACanvas.Pen.Width:= 0;
       ACanvas.Brush.Color:= PersHoverCol;
       ACanvas.RoundRect(PersonOverRect, 5, 5);
       ACanvas.GradientFill(PersonRect, NormalPersonHoverColorStart, NormalPersonHoverColorEnd, gdVertical);
       ACanvas.Font.Color:= NormalPersonFontCol;
     end
  else
  if not fSelected and not fMouseOver then
     begin
       ACanvas.GradientFill(PersonRect, NormalPersonColStart, NormalPersonColEnd, gdVertical);
       ACanvas.Font.Color:= NormalPersonFontCol;
     end
  else
  if fSelected and not fMouseOver then
     begin
       ACanvas.Brush.Style:= bsSolid;
       ACanvas.GradientFill(PersonRect, SelectedPersonColStart, SelectedPersonColEnd, gdVertical);
       ACanvas.Font.Color:= SelectedPersonFontCol;
     end;

  ACanvas.Brush.Style:= bsClear;
  ACanvas.TextRect(Rect(ATop + 5, ALeft + 5, PersonWidth - 5, PersonHeight - 5), 1, 1, AName, Style);
  ACanvas.Rectangle(PersonRect);
end;

constructor TFamilyTree.Create(AOwner: TComponent);
begin
  inherited Create(AOwner);
  Color:= ControlCol;
  fGenealogyFile:= TGenealogyFile.Create;
  fProband:= fGenealogyFile.Proband;
  fSelectedPerson:= fProband;
  for i:= 1 to 15 do
    fTreePerson[i]:= TTreePerson.Create;
end;

destructor TFamilyTree.Destroy;
begin
  inherited Destroy;
  for i:= 1 to 15 do
    fTreePerson[i].Free;
  fGenealogyFile.Free;
end;

procedure TFamilyTree.Paint;
begin
  if fProband = -1 then
     fTreePerson[1].Name:= 'Proband hinzufügen'
  else
     fTreePerson[1].Name:= fGenealogyFile.Persons[fSelectedPerson].FirstName + ' ' +
                         fGenealogyFile.Persons[fSelectedPerson].LastName;

  fTreePerson[1].Draw(fTreePerson[1].Name, Canvas, 20, 20);

  inherited Paint;
end;

end.
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 3 von 3     123   


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 03:32 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz