OOP Problem: änderungen werden nicht übernommen

[mimi]

Hallo,
Ich habe jetzt etwas viel geschrieben ich hoffe das sich jemmand die mühe macht diese
Frage durchzulesen und eine lösung für das "ausfürhlich" beschriebende problem zu finden *G*
Vielen Dank im voraus.

Ich möchte mir ein eigene "kleine" GUI schreiben.
Die nur ein paar standart komponenten hat wie z.b.
- Button
- Edit
- Formula
ersteinmal, später kann ich sie ja noch erweitern.

Ich habe mir jetzt einige gedanken gemacht für den Klassenaufbau und auch
angefangen da bin ich leider auf unerwartete probleme gestoßen.
Ich möchte ein obj per Create erstellen wie in der "Delphi GUI"
und genau hier fangen die probleme an:
ich wollte eine allgemine komponenten liste erstellen die habe ich
in der Unit definiert:

Delphi-Quellcode:

var
  GUI:TGUI;

implementation

dort sollen alle komponenten rein die mit Create erstellt werden.
TGUI sieht so aus:

Delphi-Quellcode:

  TGUI = class
  private
  public
    items:TObjectList;
    constructor Create;
    procedure Add(obj:TStdObj);
    procedure Del(Index:Integer);
    procedure Draw;
  end;

das Stanadt obj von denn allen abgeleitet werden müssen damit es
funktioniert sieht so aus:

Delphi-Quellcode:

  TSTDObj = class
  private
  public
    GFL:TMyCanvas;
    Sel:TStdObj;
    Namen:String;
    Caption:String; // Enhälst den Anzeige Text
    Hint:String; // Enhälst eine Genaue Beschreibung der Liste
    Parent:String; // Enthälst den Unterkomponente
    Typ1:String; // Benuterdefniert
    Visible:Boolean; // Sichtbar oder unsichtbar
    ShowHint:Boolean; // Beschreibung anzeigen oder nicht anzeigen
    isStdList:Boolean; // Fügt in eine Eigne Liste ein die jede komponente hat
    Typ:Integer; // Benuterdefniert
    x,y,w,h,r:Integer; // Position(x,y) Größe(w,h)
    ObjTyp:Integer; // Kreis oder Rechteck
    absX,AbsY:Integer; // Abstand zum Rand
    onMouseMove:TMouseMove;
    onMouseUp:TMouseUp;
    onMouseDown:TMouseDown;
    onMouseLave:TMouseLave;
    onKeyDown:TKeyDown;
    onKeyPress:TKeyPress;
    onKeyUp:TKeyUp;
    constructor Create(h:HWND;obj:Tobj);
    procedure Draw;

  end;

Jedes obj gehört zu einem Formual ohne gehts nicht:

Delphi-Quellcode:

  TFormula = class(TStdObj)
  private
    MoveT:Integer;
  public
    Titel_W,Titel_H,Titel_X,Titel_Y:Integer;
    f:TForm;
    EnabledColor:TColor;
    constructor Create(Form:TForm; pCaption:String);
    procedure Draw;
    procedure Click(px,py:Integer;Button: TShiftState);
    procedure MoveUp(px,py:Integer;Button: TMouseButton);
  end;

implementation

constructor TFormula.Create(Form:TForm;pCaption:String);
begin
  inherited Create(Form.Handle,self);
  EnabledColor:=clRed;

  f:=Form;
  x:=0; y:=0; w:=form.Width; h:=Form.Height;
  Titel_W:=w; Titel_H:=20; Titel_X:=0; Titel_Y:=0;
  Form.BorderStyle:=bsNone;
  Form.Position:=poDesigned;
  Caption:=pCaption;
  MoveT:=-1;
end; // Create

// aufruf
procedure TForm1.FormCreate(Sender: TObject);
var
  Button:TMyButton;
begin
  f:=TFormula.Create(Form1,'Dies ist ein kleiner test');
  f.namen:='Form1';

  button:=TMyButton.Create(Form1.Handle,button);
  button.Caption:='Hallo';
  button.Namen:='button1';
  button.x:=10;
  button.y:=10;
  Button.w:=10;
  Button.h:=10;


  f.absX:=2;
  f.absY:=2;

end;

Das Problem ist jetzt wenn ich ein variable änder z.b. den Caption wird dies leider nicht in die obj liste übernommen.
und ich möchte gerne das diese auch übernommen werden. d.h. alle variablen die ich änder kann sollen auto. in
die obj liste übernommen werden. ich dachte mir das ein "zeiger" oder was änliches auf das gerade erstelle obj
zeigt. Wie z.b. mit folgedner defniation:
  test:=test3 jetzt wird ja test mit test3 verküpft und so dachte ich mir das in meinem problem auch.
Das ganze soll wie in der Delphi GUI ablaufen. Dachte ich mir.
ich hoffe ihr versteht worauf ich hinaus möchte.

Anmerkung:
ich schreibe zwar schon seit ca 5-7 Jahren in Delphi meine Programme aber mit der OOP
habe ich bis noch nicht so ausführlich gearbeitet d.h. Ich habe schon klassen defniniert
und ereignisse und eigenschaften erstellt nur was ich bis jetzt noch nicht getan habe ist
mit vererbungen zu arbeiten also das "eigentliche" oop.

[jbg]

Dazu rate ich dir mal ein OOP Tutorial durchzulesen. Dann wirst du sehen, dass z.B. die Draw-Methode am besten virtuell sein sollte, und was man unter Information-Hiding versteht. Feld-Deklarationen haben nichts im public-Bereich zu suchen, sondern gehören in den private-Bereich. Im protected unt public-Bereich wird dann per Eigenschaften (=> property) der Zugriff geregelt. So kann man z.B. mit "property Caption: string read FCaption write SetCaption;" auf die Veränderung der Caption mit einem Neuzeichnen reagieren, was mit deinem aktuellen Programmcode nicht geht.


Und nun noch zur Deutschen Sprache:
Die Art zu Stehen hat nichts mit dem Standard zu tun. Warum schreiben eigentlich 70% aller Deutschen das Wort immer falsch. Irgendwas muss da in den Schulen wohl falsch laufen. Vielleicht sollte man der Dudenkommision auch mal die "Art zu Stehen" als alternative für "Standard" vorschlagen.

Auch wenn man in der gesprochenen Sprache bei "Formular" das "r" verschluggt, wird es trotzdem geschrieben

[mimi]

Vielen Dank. Das tutor werde ich mir gleich mal durchlesen. evlt. gibt es ja anregungen für die Klassenstrucktur.

Zitat:

Warum schreiben eigentlich 70% aller Deutschen das Wort immer falsch.

schön dann bin ich wenigents mit diesem Problem nicht alleine !

[mimi]

ich habe mir das Tutor durchgelesen und wollte eine Klassenstruckur schreiben die sieht jetzt so aus. dazu habe ich einige fragen:

Delphi-Quellcode:

unit uStdObj;

interface

type
  TStdObj = class
  private
    FName:String; // Enhält den Namen des Obj
    FCaption:String; // Enhält das was Angezeigt wird
    FTag:Integer; // unBelengt
    Fx:Integer; // die X Position vom OBJ
    Fy:Integer; // die Y Position vom ObJ
    fw:Integer; // Die Breite vom Obj
    Fh:Integer; // die Höhe vom Obj
    procedure SetCaption(Caption:String);
    procedure SetnNmen(Namen:String);
  public
    constructor Create(obj:TStdObj);
    destructor Free;
    procedure Draw
  published
    property Name:string read fName write fName;
    property Caption:string read fCaption write fCaption;
  end;

implementation

constructor TStdObj.Create(obj:TStdObj);
begin
end; // Create

destructor TStdObj.Free;
begin
end; // Free

procedure TStdObj.SetCaption(Caption:String);
begin
  fCaption:=Caption;
  Draw;
end; // SetCaption

procedure TStdObj.SetNamen(Namen:String);
begin
  fNamen:=Namen;
  Draw;
end; // SetNamen

end.

1: Eigenschafen:
Ich möchte gerne das bei jede änderung eine eigenschft die procedure Draw danach ausgeführt wird. Muss ich das denn so "aufwendig" schreiben wie ich das mit namen und Caption gemacht habe, oder kann ich das auch etwas kürtzer schreiben.

2: Strucktur:
Ist die strucktur bis jetzt sinvoller als die "alte" ?

[Der_Unwissende]

Zitat von mimi:

1: Eigenschafen:
Ich möchte gerne das bei jede änderung eine eigenschft die procedure Draw danach ausgeführt wird. Muss ich das denn so "aufwendig" schreiben wie ich das mit namen und Caption gemacht habe, oder kann ich das auch etwas kürtzer schreiben.

Ja, du solltest es genau so machen, wie du es für Caption und Namen gemacht hast. Es ist durchaus sinnvoll das so zu tun, da du unter gewissen Umständen (Die Komponente wird noch viel größer) vielleicht spezielle Parameter übergeben möchtest, nur partiell zeichnet, gar nicht zeichnest (nicht sichtbare Eigenschaften...).

Zitat von mimi:

2: Strucktur:
Ist die strucktur bis jetzt sinvoller als die "alte" ?

Das definitiv. Aber es gibt immer noch ein paar Dinge die ich bemängeln würde. Als erstes mal die Properties, du benutzt jetzt schon richtig Properties und hast auch setter für diese geschrieben, vielleicht solltest du diese auch verwenden!

In den Aufruf des Konstruktors sollte unbedingt immer als erstes ein Aufruf des Vorgänger Konstruktors (analog beim Destruktor).
Und dein Destruktor sollte Destroy heißen (und ein override bekommen). Free solltest du nicht überschreiben, da Free nicht mehr macht als zu schauen ob die Instanz noch existiert (Referenz <> nil) und dann Destroy aufruft.

Wenn dies die Basisklasse ist, von denen andere Objekte abgeleitet werden sollen, dann solltest du zudem darüber nachdenken, die setter lieber protected zu deklarieren (selbes würde ich mit draw machen). Für Draw wäre dann noch interessant wohin du zeichnen lassen möchtest. Ach ja, einige Methoden (hier natürlich nur draw) solltest du in der Basisklasse einfach mal abstract lassen. Ich weiß nicht ob du in deinem Tut auch schon was über Interfaces und abstrakte Klassen gelesen hast, aber die sind in der OOP von hoher Bedeutung, da du mit ihnen sehr viel sehr elegant lösen kannst.

Wie gesagt, dein Ansatz ist schon deutlich besser als der erste, aber ich denke du wirst noch viel lernen (während der Entwicklung). Wichtig ist es halt, möglichst gut vorbereitet zu starten, Fehler vermeiden kostet immer viel viel weniger als welche Nachträglich zu beseitigen.

Gruß Der Unwissende

[mimi]

was meisnt du mit "setter" ?

Zitat:

Wichtig ist es halt, möglichst gut vorbereitet zu starten, Fehler vermeiden

das möchte ich dies mal wirklich tuen da es ein größers porjekt wird wolte es ich von anfang an gleich richtig planen. Darum frage ich auch hier.

Zitat:

Für Draw wäre dann noch interessant wohin du zeichnen lassen möchtest.

dafür ist ja fx und fy veranwortlich oder was meinst du mit dieser frage ?
ich möchte auch nur das obj neu zeichen lassen was sich gerade ändert.

Zitat:

Ich weiß nicht ob du in deinem Tut auch schon was über Interfaces und abstrakte

habe ich. Aber ich weiß im moment nicht was ein Interfaces hier zu tuen hätte ich stelle mir ein interfaces immer so vor:
du möchte eine grafik engine schreiben und möchtes verschiende grafik system verwenden z.b. openGL, DX, Canvas, etc. aber bei meiner GUI wüste ich jetzt nicht wo es da verwendung finden sollte.

eine frage habe ich aber noch:
verwaltung der obj.
ich möchte gerne das jedes obj z.b. ein panel sein obj. selsbt verwalten kann dies soll über ein schalter gemacht werden. d.h. wenn diese schalter auf True ist soll die eigene liste verwendet werden und wenn dierser auf False ist(standart einstellung) soll es in die allgemeine liste eingefügt werden.
Problem ist hier die umsetzung. Ein kleines beispiel währe nicht schlecht. Ich wollte wohl TObjectList nehmen..

Da dies mein erstes richtiges OOP programm ist wollte ich es gleich richtig planen damit ich nicht alles von vorne schreiben muss weil ich festelle das irgenwas nicht funktioniert.
Das währe ja ärgerlich.

[mimi]

das ist die "neue klasse" habe ein paar änderung gemacht die ich übersehen hatte

Delphi-Quellcode:

TStdObj = class
  private
    FName:String; // Enhält den Namen des Obj
    FCaption:String; // Enhält das was Angezeigt wird
    FTag:Integer; // unBelengt
    Fx:Integer; // die X Position vom OBJ
    Fy:Integer; // die Y Position vom ObJ
    fw:Integer; // Die Breite vom Obj
    Fh:Integer; // die Höhe vom Obj
    procedure SetCaption(Caption:String);
    procedure SetNamen(Namen:String);
  public
    constructor Create(obj:TStdObj);
    destructor Free;
    procedure Draw;
  published
    property Name:string read fName write SetNamen;
    property Caption:string read fCaption write SetCaption;
  end;

ps: warum wird Name als schlüsswort hier angezeigt und nicht als normale variable ?

[Der_Unwissende]

Zitat von mimi:

was meisnt du mit "setter" ?

Wenn du Properties verwendest, dann ja eigentlich nur aus der Idee heraus, nicht direkt auf einen Wert zu zugreifen. Dafür gibt es gleich mehrere Gründe, einerseits interessierst du dich in der OOP nie für die konkrete Art wie ein Wert abgespeichert wird. Ob es in einer Liste, einem Array, einer Hashtable, einem Baum, einer Halde,.... ist ändert für dich (von aussen kommend) nichts. Das andere ist natürlich, dass du gerne Invarianten überprüfen möchtest (Vor- und Nachbedingungen).
Deswegen sind Variablen in der OOP eigentlich immer privat und du greifst eigentlich nie direkt auf sie zu (es lässt sich immer vermeiden). Statt dessen benutzt du eine Methode, die einen Wert setzt (Setter) und eine Methode die dir einen Wert liefert (Getter).
Natürlich wird dir der Setter häufiger begegnen (hier prüfst du beim setzen ob der Wert gültig ist). Aber auch getter machen Sinn, wenn du zum Beispiel eine Liste von Zahlen hast und die größte Zahl bekommen möchtest, könntest du entweder immer die größte Zahl in einer Variablen speichern oder du sortierst die aufsteigend und nimmst das letzte Element oder du durchläufst die gesamte Liste und suchst das Größte. Wie du siehst leisten alle Methoden genau das gleiche, doch warum sollte es dich von aussen kommend interessieren? Du willst nur das größte Element. Hast du jetzt eine Methode getGreatestOne, liefert die dir irgendwie das Größte Element (alles was du willst).
In Delphi verbergen Properties nur den expliziten Aufruf solcher Methoden (du kannst natürlich auch direkt die Variable schreiben oder lesen).

Zitat von mimi:

Zitat:

Für Draw wäre dann noch interessant wohin du zeichnen lassen möchtest.

dafür ist ja fx und fy veranwortlich oder was meinst du mit dieser frage ?
ich möchte auch nur das obj neu zeichen lassen was sich gerade ändert.

Ich meine du möchtest so etwas wie einen Button zeichnen, dann musst du doch angeben wohin gezeichnet werden soll. Wenn du dir in Delphi die "Draws" anschaust, wirst du häufig sehen, dass man ein Canvas übergibt auf das gezeichnet werden kann. Das wäre eventuell auch bei dir nötig. Aber ich glaube du möchtest jetzt erstmal nur fertige Buttons (u.Ä.) platzieren, oder?

Zitat von mimi:

habe ich. Aber ich weiß im moment nicht was ein Interfaces hier zu tuen hätte ich stelle mir ein interfaces immer so vor:
du möchte eine grafik engine schreiben und möchtes verschiende grafik system verwenden z.b. openGL, DX, Canvas, etc. aber bei meiner GUI wüste ich jetzt nicht wo es da verwendung finden sollte.

Nun ja, Interfaces sind echt wichtig zu verstehen. Sie bieten einem wie gesagt eine Menge Möglichkeiten.
Ein Interface ist erstmal nur eine Sammlung an Methoden. Du weißt nur durch die Dokumentation was die einzelnen Methoden machen sollen und du weißt was für Argumente sie bekommen. Das wars. Ein Interface implementiert aber keine dieser Methoden.
Jede Klasse kann von genau einer Klasse erben, sie kann aber zusätzlich noch beliebig viele Interfaces implementieren. Ein Interface zu implementieren heißt dabei, dass jede abstrakte Methode des Interfaces in der Klasse implementiert werden muss.
Implementiert also eine Klasse ein Interface, so wird dir zugesichert, dass diese Klasse alle Methoden des Interface besitzt.

Das eigentlich Wichtige an diesen Dingern ist eben diese Zusicherung. Wenn du dein Programm erweiterst, möchtest du nicht für jede Erweiterung das Rad neu erfinden (nicht in der OOP). Also versuchst du den gemeinsamen Nenner zu finden und zu verwenden. Wichtig ist, dass jede Klasse immer die Eigenschaften ihrer Vorfahren und der implementierten Interfaces hat. Ein Interface entspricht weitgehend einer abstrakten Klasse, allerdings besitzt ein Interface ausschließlich abstrakte Methoden (eine abstrakte Klasse besitzt nur mindestens eine abstrakte Methode).

Das ganze mal etwas deutlicher an einem Beispiel:

Delphi-Quellcode:

type
  TDrawable = Interface
    procedure setPosX(const Position : Integer);
    procedure setPosY(const Position : Integer);
    procedure Draw(const Canvas : TCanvas);
  end;

  TDrawableButton = class(TInterfacedObject, TDrawable)
    protected
      procedure OnClick;
    public
      procedure setPosX(const Position : Integer);
      procedure setPosY(const Position : Integer);
      procedure Draw(const Canvas : TCanvas);
  end;

  TDrawablePanel = class(TInterfacedObject, TDrawable)
    private
      FPosX, FPosY : Integer;
      FColor : TColor;
    protected
      procedure setColor(const Color : TColor);
    public
      procedure setPosX(const Position : Integer);
      procedure setPosY(const Position : Integer);
      procedure Draw(const Canvas : TCanvas);      
      property Color : TColor read FColor write setColor;
  end;
....
  procedure doFoo;
  var Drawable : TDrawable;
  begin
    DrawAble := TDrawablePanel.Create;
    // Achtung, DrawAble hat nur die Eigenschaften des Inteface!
    // also nur die Methoden setPosX/Y und Draw
    DrawAble.Draw(Form1.Canvas);
    ...
  end;

Ok, kein großartiges Beispiel, aber soll ja auch nur kurz etwas zeigen. Hier siehst du erstmal dass du zwei verschieden Objekte mit unterschiedlichen Eigenschaften hast. Ein TDrawableButton hat eine Methode OnClick, aber eben keine Farbe, diese hat dann aber ein TDrawablePanel. Trotzdem sind beide vom Typ TDrawable, besitzen also beide eine Methode draw zum Zeichnen und bei beiden kann man die X und Y Position setzen. In diesem Beispiel wird der Sinn vielleicht noch nicht all zu klar, aber vielleicht siehst du schon, dass du nun ein beliebiges TDrawable auf immer den selben Canvas zeichnen könntest. Dazu übergibst du nur noch ein TDrawable, du weißt ja dass es ein Draw hat. Diesem Draw übergibst du den Canvas auf den gezeichnet werden kann und dich interessiert es nicht ob es sich um ein TDrawableButton, TDrawablePanel oder gar ein TDrawableHastDuNichtGesehen handelt.

Genauso leicht kannst du so ein TNotifyable definieren, dass eine Nachricht annimmt. Wenn du nun ein Hauptinstanz hast, die eine Liste von TNotifyalbes verwaltet, dann müsstest du bei einem Ereignis nur jedem dieser Objekte die Nachricht übergeben...

Hoffe du siehst was ich meine, ist wirklich wichtig in der OOP. Kommen neue Klassen hinzu, ist dir das egal. Implementieren sie ein Interface, stellen sie mindestens diese Funktionen zur Verfügung und mehr interessiert dich dann garnicht.

Zitat von mimi:

eine frage habe ich aber noch:
verwaltung der obj.
ich möchte gerne das jedes obj z.b. ein panel sein obj. selsbt verwalten kann dies soll über ein schalter gemacht werden. d.h. wenn diese schalter auf True ist soll die eigene liste verwendet werden und wenn dierser auf False ist(standart einstellung) soll es in die allgemeine liste eingefügt werden.
Problem ist hier die umsetzung. Ein kleines beispiel währe nicht schlecht. Ich wollte wohl TObjectList nehmen..

Ich verstehe dein Frage ehrlich gesagt nicht ganz. Was heißt denn "sein obj. selbst verwalten?". Genauer gesagt was soll denn verwaltet werden? Wenn du hier so etwas wie Kinder haben meinst, da würde ich dir auch zu einer TObjectList raten. Auch zu Interfaces, wenn du hier ein Interface hast, dass ein Add und ein Remove (oder Ähnliches) bietet, dann könntest du damit leicht in jeder Klasse die dieses Interface implementiert ein Objekt hinzufügen oder entfernen.

Gruß Der Unwissende

[mimi]

Zitat:

Ich verstehe dein Frage ehrlich gesagt nicht ganz. Was heißt denn "sein obj. selbst verwalten?". Genauer gesagt was soll denn verwaltet werden? Wenn du hier so etwas wie Kinder haben meinst, da würde ich dir auch zu einer TObjectList raten. Auch zu Interfaces, wenn du hier ein Interface hast, dass ein Add und ein Remove (oder Ähnliches) bietet, dann könntest du damit leicht in jeder Klasse die dieses Interface implementiert ein Objekt hinzufügen oder entfernen.

Nun ja z.b. ich habe jetzt 20 Komponenten erstellt(egal was) wird ja 20 mal die Create funtkion des standart obj aufgerufen. Diese obj. werden dann einmal gezeichnet was ist aber wenn ein bestimmte Komponenten neugezeichnet werden soll/muss wie greife ich auf diese komponenten zu ?
z.b.:
2 Diese Komponenten müssen neugezeichnet werden a: wie finde ich herraus welche das sind ?
b: wie kann ich auf diese zugreifen ?

hätte ich eine liste mit komponenten könnte ich ja einfach schauen wo sollgeändert werden auf True steht, weißt du was ich damit meine ?

und mit selber verwalten dachte/meine ich folgendes:
Unter Delphi gibt es ja eine "Lange" liste in mit komponenten die ich auf dem Formular habe, richtig ? d.h. alle komponenten die auf dem panel sind sind auch in der "allgemeine" liste. geau das wollte ich ändern. alle komponenten die komponenten aufnehmen soll sollen auch über eine eigene liste verfügen.

Natürlich währe das durchsuchen wird schwrig, z.b. wenn ich eine bestimmte komponente suchen muss dann muss ich ja ersteinaml die 1. liste durchsuchen und dann die weitern aber welche ?
da fällt mir im moment nur eine lösung ein:
in der 1. liste steht ein verweis auf die andern listen.
das kann ich ja beim installsiern feststellen.
Weißt du wie ich es mir vorstelle ?

oder mal andres(genau das gleiche problem nur anderes beschrieben):
Ich habe die 20 Komponenten und möchte auf die 2 zugreifen z.b. über FindKomponente(2) oder FindKomponente('Zweitekomponente');

Vielen dank für deine Tipps. Nur das mit den interface verstehe ich immer noch nicht so ganz. scheint aber ein mächtige funktion zu sein in der OOP. Das mit der Draw funktion wollte ich auch indrect nutzen.

weil ich nutze für die Grafik dastellung nicht canvas sonder direkt die GDI habe da eine unit gefunden:http://www.benibela.de
ich habe jedoch ein kleine extra unit geschrieben die die verwendung vereinfacht *G*

mit Setter und Getter meinst du sowas:
Setter=procedureen die was Setzten
Getter=funktionen