Ähnliche Funktionen von Klassen - Implementierung?

[scrat1979]

Hallo zusammen,

ich habe - bevor ich mich bei meinem aktuellen Programm in eine Sackgasse bewege - eine Frage. In meinem Programm (soll ein Dienstplan für meine Abteilung werden) gibt es 3 Diensttypen, nennen wir sie mal Dienst 1 - 3. Diese greifen jeweils auf eine DB-Tabelle zu (ist Firebird aber in dem Zusammenhang irrelevant). Die Dienste bzw. die Datenbankabfragen der Dienste unterscheiden sich lediglich in den Namen der Datenbankfelder. Wie implementiere ich dies am sinnvollsten? Momentan sieht es im übrigen NICHT so aus, als würde sich die Anzahl der Dienste (also Dienst 4,5,6 etc.) irgendwann vergrößern, eine Garantie habe ich aber dafür nicht. Meine 2 Ideen:

1.) Eine Klasse, im Konstruktor wird die Dienstart (z.B. als Integer) übergeben. Die Datenbankabfragen (genauer die Feldnamen) werden dann ja nach Integer-Wert in den entsprechenden Routinen z.B. mittels "CASE DienstArt OF [...]" verändert.

2.) Eine abstrakte Klasse, wobei ich für die verschiedenen DienstArten jeweils eine eigene KLasse davon ableite und die Datenbankabfragen hier jeweils getrennt implementiere.

Für 1. spricht meiner Meinung die einfachere Implementierung. Sollte sich irgendwann einmal die Abfrage(n) ändern, müsste ich nur diese eine Klasse verändern, bei 2. wären die (wie beschrieben) sehr ähnlichen Abfragen - da abstrakt deklariert - alle zu ändern.

Für 2. spricht für mich eigentlich nur die Einhaltung des OOP-Prinzips, die Pflege scheint mir hier deutlich aufwendiger

Ich hoffe, Ihr könnt meinem Gedankengang folgen bzw. vielleicht habt ihr ja noch eine viel einfachere Idee.

Grüsse,

Michael

[mkinzler]

Ich würde diese Informationen "normalisiewren". D. h. selbe Felder in verschiedenenen "Zeilen"

[scrat1979]

Hmmm, also hier mal der Aufbau einer der Tabellen (auf die wichtigsten Felder gekürzt=, damit es klarer wird:

Code:

CREATE TABLE TAB_TAGE (
  ID INTEGER NOT NULL,
  DATUM DATE NOT NULL,
  FEIERTAG SMALLINT DEFAULT 0 NOT NULL,
  FARBEBEREITSCHAFT INTEGER,
  FARBENOTARZT INTEGER,
  FARBERUFDIENST INTEGER);

Erklärung (wie gesagt, ist nur ein Beispiel!). Bei dieser Tabelle handelt es sich letztlich um nichts anderes als ein Monatskalendar. Nun gibt es - wie gesagt - 3 Dienstarten. Diesen kann der Benutzer im Kalendar zur Markierung eine Hintergrundfarbe verpassen. Diese Farbe wird in dieser Tabelle hinterlegt (Ein Tag = 1 Zeile). Die eigentlichen Dienste werden in einer separaten Tabelle über einen FK gespeichert (zwecks Normalisierung). Möchte ich nun EINE Klasse haben, um die jeweilige Hintergrundfarbe auszulesen, hätte ich ja - bei JEDER Abfrage, welche sich auf dienstspezifische Felder bezieht - folgendes oder ähnliches Konstrukt:

Delphi-Quellcode:

  case DienstTyp of
    1 : FeldName := 'FARBEBEREITSCHAFT';
    2 : FeldName := 'FARBERUFDIENST';
    3 : FeldName := 'FARBENOTARZT';
  end;

  FQuery.SQL.Clear;
  FQuery.SQL.Add('UPDATE tab_tage');
  FQuery.SQL.Add('SET %FeldName% = :FARBE');
  FQuery.SQL.Add('WHERE id = :DBID;');
  FQuery.SQL.Text := StringReplace(FQuery.SQL.Text, '%FeldName%', FeldName, []);

Teile ich es jedoch in 3 Klassen auf, kann ich mir die CASE-Abfrage sparen (hier exemplarisch für Dienst 2), hätte aber wegen der abstrakten Methoden in der Basisklasse haufenweise redundanten Quellcode:

Delphi-Quellcode:

  FQuery.SQL.Clear;
  FQuery.SQL.Add('UPDATE tab_tage');
  FQuery.SQL.Add('SET FARBERUFDIENST = :FARBE');
  FQuery.SQL.Add('WHERE id = :DBID;');

P.S.: Ich denke nicht, dass es in diesem Fall sinnvoll ist, eine weitere Tabelle für die 3 Farben zu erstellen und über einen FK zu referenzieren, oder?!?

[Namenloser]

Ich verstehe nicht ganz, wieso es 3 Felder für die Farbe gibt - wieso reicht nicht eines?

Was den redundanten Code angeht: Du kannst das ganze ja in etwa so machen:

Delphi-Quellcode:

TBasisKlasse = class
protected
  function GetFieldName: string; virtual; abstract;
public
  procedure DoSomething;
end;

TKlasse 1 = class(TBasisKlasse)
protected
  function GetFieldName: string; override;
end;

TKlasse 2 = class(TBasisKlasse)
protected
  function GetFieldName: string; override;
end;

procedure TBasisKlasse.DoSomething;
begin
  { viel code ... }
  FQuery.SQL.Text := 'UPDATE xyz SET '+GetFieldName+'=123 WHERE id=3';
  {viel code ... }
end;

function TKlasse1.GetFieldName: string;
begin
  Result := 'Klasse1Farbe';
end;

function TKlasse2.GetFieldName: string;
begin
  Result := 'Klasse2Farbe';
end;

Alternativ kann man natürlich auch den jeweiligen Namen im Konstruktor in einem Feld speichern. Bei komplexeren Sachen bitet sich die obere Methode aber an. Ich glaube es gibt auch einen Namen für dieses Pattern, aber das will mir jetzt nicht einfallen...

Aber wie gesagt erschließt sich mir in deinem Fall der Sinn nicht ganz.

[scrat1979]

Zitat:

Zitat von NamenLozer (Beitrag 1035554)

Ich verstehe nicht ganz, wieso es 3 Felder für die Farbe gibt - wieso reicht nicht eines?

[...]

Aber wie gesagt erschließt sich mir in deinem Fall der Sinn nicht ganz.

Ok, ich werde nachher mal einen Screenshot anhängen, ich denke, dann wird das alles klar werden. In Worten vorweg: Die (visuelle) Tabellenansicht [hat nichts mit der Datenbank zu tun, ein frisiertes StringGrid] besteht aus 4 Spalten

DATUM DIENST1 DIENST2 DIENST3
1.1.2010 Herr xzy Frau dfdf Herr asdlkf
[...]
31.1.2010 Herr dfdf Herr sdkf Herr dsfsdf


Nun kann z.B. am 31.1.2010 der Dienst 2 farbig hinterlegt werden. Das wird - in diesem Falle - in der o.g. Datenbanktabelle unter FARBERUFDIENST im entsprechenden Datensatz gespeichert.

Ich hoffe, mit diesen Informationen schonmal etwas Licht ins Dunkel zu bringen. Screenshot folgt später...

Michael

[EDIT] Screenshot angehängt, die rosa Pfeiler markieren die Hintergründe, von links nach rechts o.g. Datenbankfeldern zugehörig. Hoffe, es wird jetzt klar, wie das später aussehen soll...

[Namenloser]

Ah, ich glaube, ich verstehe es jetzt. Aber wäre es nicht viel leichter, ein Feld für die Farbe in der Dienste-Tabelle anzulegen statt 3 felder in der Tage-Tabelle?

Oder wenn du das aus Design-Gründen nicht willst, kannst du natürlich auch wie von dir oben beschrieben eine neue Tabelle anlegen mit einem Foreign-Key anlegen, in der du jeweils die Farbe dem Dienst zugeordnet ist. Sieht vielleicht etwas komisch aus, weil die Tabelle dann nur 2 Felder hat - aber warum eigentlich nicht.

[scrat1979]

Die Idee ist mir vorher auch gekommen. Nur wenn ich den Dienst (= Datensatz) aus der Tabelle lösche dann ist auch die Farbcodierung weg. Diese sollte jedoch auch ohne Dienst-Eintrag persistieren. Ich denke, dann werde ich wohl eine eigene Tabelle machen und per Join mit dem Dienst verbinden. Danke schonmal für die vielen Antworten, ich werde mich bestimmt wieder bei Euch melden :)

Michael