Frage zum Thema OOP

[Net7]

Hi Leute,

Zur Zeit setze ich mich mit OOP auseinander. Mir ist auch im Grunde klar wie es funktioniert, nur habe ich Probleme beim Planen von OOP Projekten.

Mir kommt es so vor als wüsten die Leute die Objektorientiert programmieren von Anfang an wie das Programm funktionieren soll. Ok, bei einem Taschenrechnerprogramm kann ich das noch nachvollziehen, aber bei grösseren Programmen verliere ich den Faden.

Man kann doch nicht alles berücksichtigen. :wall:

Wie plant man sowas?? :coder2:

[Hansa]

Zitat:

Zitat von Net7

...Man kann doch nicht alles berücksichtigen. :wall:

Ich glaube, das Prinzip ist doch nicht so klar, wie Du denkst. 8) Es gibt ja so schöne Beispiele wie Fahrrad und LKW. Ich verwende mal lieber ein Delphi-Beispiel : TEdit. Ich will jetzt eines, das nur Zahlen aufnimmt. Das TEdit an sich braucht darüber aber überhaupt nichts zu wissen. Ich leite es aber davon ab, indem ich ihm eine neue OnKeyPress Eigenschaft verpasse :

Delphi-Quellcode:

  TIntEdit = class(TEdit)
  protected
    procedure KeyPress(var Key: Char); override;
  end;

Das override sagt, daß die ursprüngliche Methode durch die neu definierte ersetzt wird. Das ganze ist im protected Teil, weil ich es eventuell später weiter ableiten will. Die konkrete Prozedur sieht nun so aus :

Delphi-Quellcode:

procedure TIntEdit.KeyPress(var Key: Char);
begin
  inherited KeyPress(Key);
  if not (Key in ['0'..'9']) then
    key := #0;
end;

Durch das inherited wird sichergestellt, daß alle dem TEdit bekannten Methoden auch dem neuen TIntEdit bekannt sind. Die Planung spielt hierbei nur eine untergeordnete Rolle. Was ist, wenn einem später bewußt wird, daß es auch Gleitkommazahlen gibt ? :shock:

Buchstaben sollen so oder so nicht zugelassen werden, wohl aber ein DecimalSeparator. Also geht man vom TIntEdit aus und ändert das ab :

Delphi-Quellcode:

TRealEdit = class(TIntEdit)

procedure TRealEdit.KeyPress(var Key: Char);
begin
  inherited KeyPress(Key);  // nur 0..9 werden zugelassen, sonst :
  if (Key <> DecimalSeparator]) then  // hier auch noch , oder . zulassen
    key := #0;
end;

Sehr beliebt ist es allerdings auch, solche Konstrukte direkt von TControl abzuleiten, was bedeutet, das Rad komplett neu zu erfinden. Wer so was macht, der hat OOP einfach nicht verstanden. Denn das Geheimnis liegt lediglich darin, den am besten geeigneten Basistyp als Grundlage zu nehmen.

[jbg]

Zitat:

Zitat von Hansa

Sehr beliebt ist es allerdings auch, solche Konstrukte direkt von TControl abzuleiten

Von TControl? Bist du dir da sicher? Oder meintest du TGraphicControl bzw. TWinControl/TCustomControl? Wenn man nämlich von TControl ableitet kommt man nicht all zu weit.

[KrasserChecker]

Zitat:

...Man kann doch nicht alles berücksichtigen. ouch!

Muss man auch gar nicht. Grundvorausetzung, um ein Programm zu schreiben ist ja sowieso, dass man weiss, was man am Ende als Ergebnis haben möchte. Genau dazu gibt es ja Pflichtenhefte.
Mit dem Planen fängt man dann erstmal grob an und geht dann erst später ins Detail.
Beispiel:

Ich weiss, dass ich eine Datenbank benötige. Also sehe schon mal vor, später darauf Zugriff zu haben, wenn ich es brauche. Wie genau das dann in der Implementation aussieht ist dabei erstmal egal.
Dann geht's nach dem gleichen Prinzip um die Oberfläche: Welche Information brauche ich wo und wie. Wo die herkommn und wie die Oberfläche aussieht ist erstmal egal.

Erst wenn das Grundprinzip steht kümmert man sich dann um den tatsächlichen Inhalt. Das ganze fällt dann unter den Begriff "Kapselung". Ich weiss also erstmal, was ich will. Wie das dann intern abläuft interessiert (erstmal) nicht.

Das ganze erfordert natürlich einen Haugen Planung, dass Ergebnis rechtfertigt allerdings (fast immer) den Aufwand.

[MrSpock]

Hallo Net7,

nein natürlich wissen Entwickler nicht komplett, was am Ende rauskommen soll. Es gibt aber Hinweise, wie man vorgehen soll. Grundsätzlich wird heute häufig das V-Modell (siehe z.B. hier) angewandt und zwar nicht nur für öffentliche Aufträge. Dabei werden verschieden Phasen und entsprechende Phasendokumente beschrieben, die in einem Entwicklungsprozess vorkommen. Für die Analyse solltest du objekt orientiert arbeiten. Die Ergebnisse vieler Phasen werden heute in UML festgehalten. Dort beginnt man in der Regtel mit sogenannten Use Cases, erstellt danach Activity Diagrams und darauf aufbauend Class Diagrams. Mit State Events, Interaction Diagrams und Packages stehen weiter Hilfsmittel zur Verfügung. Alle Phasen werden iterativ immer wieder durchlaufen und die Ergebnisse erweitert, bis das gesamte Produkt steht. Schau dir mal Bücher zum Thema Objektorientierte Analyse und Design mit UML an. Dort werden diese Aspekte häufig gut beschrieben.

[Net7]

Vielen dank schon mal für die Antworten.

@Hansa, Vielen Dank für deine Mühe,und deine Beispiele.Aber wie man Objecte ableitet ect. das weiß ich. Darum gehts aber nicht. Es geht nur um die Planung.


@KrasserChecker

Na dann bin ich ja beruigt, also wächst die Planung mit dem Projekt. Das hört sich gut an.


@MrSpock

joa.. UML ist eine feine Sache, das mit den VDiagramm werd ich mir mal genauer anschauen.




Bleibt nur zu hoffen das man nach einer bestimmten Größe des Projekts, nicht den Überblick verliert.

[Jelly]

Zitat:

Zitat von Hansa

Buchstaben sollen so oder so nicht zugelassen werden, wohl aber ein DecimalSeparator. Also geht man vom TIntEdit aus und ändert das ab :

Delphi-Quellcode:

TRealEdit = class(TIntEdit)

procedure TRealEdit.KeyPress(var Key: Char);
begin
  inherited KeyPress(Key);  // nur 0..9 werden zugelassen, sonst :
  if (Key <> DecimalSeparator]) then  // hier auch noch , oder . zulassen
    key := #0;
end;

Jaja, das ist wohl etwas überhastet gewesen. Durch den Aufruf von inherited Keypress aus TIntEdit kriegst du Key = #0 zurück, wenn nicht eine Zahl gedrückt wurde. Das also auch beim Decimalseparator. Nach dem Aufruf ist Key also #0, und den Vergleich mit DecimalSeparator ist überflüssig :zwinker:

[Hansa]

@Jelly : jo. :mrgreen:

In der Praxis siehts so aus :

Delphi-Quellcode:

constructor TIntEdit.Create(AOwner: TComponent);
begin
  inherited;
  ZulZeichen := ['0'..'9',#8];
  FAlignment := taRightJustify;
end;

procedure TIntEdit.KeyPress(var Key: Char);
begin
  inherited KeyPress(Key);
  if not (Key in ZulZeichen) then
    key := #0;
end;

{ TRealEdit }

constructor TRealEdit.Create(AOwner: TComponent);
begin
  inherited;
  ZulZeichen := ZulZeichen + [DecimalSeparator];
end;

"ZulZeichen" steht ab TIntEdit zur Verfügung. Da ist nun aber wirklich nicht viel zu planen, geschweige denn, seine Zeit mit dem Entwurf irgenwelcher Diagramme zu verplempern. 8) Später hat man dann nämlich nicht nur seine Programme zu warten, sondern auch noch die Diagramme. IMHO bringen solche Dinge nur in Ausnahmefällen eine Verbesserung, im Normalfall ist es eher ein Hindernis.

[schöni]

Hallo Hansa!

Da muss ich mich mal reinhängen. Für Dein Beispiel hast Du recht. Aber was ist bei wirklich großen Projekten. Bei großen Datenbanken im LAN oder Internet? Oder nehmen wir die VCL. Die mußte erst mal entwickenlt werden, damit Du Dein TEdit, wir unsere Klassen davon ableiten (kannst) können. Mag sein, das die UML-Listen auch gewartet werden müssen. Dann ergäbe sich an dieser Stelle die Notwendigkeit der Weiterentwicklung. Meiner Ansicht nach kannst Du aber bereits mit ModelMaker und/oder Together von Borland auf UML-Basis Deine Anwendung entwickeln und Delphi baut Dir den passenden Quelltext (ab Delphi 8) Ich habe sowas in Köln auf der Borland Roadshow zu Delphi 8 gesehen. Die haben mit nem UML Tool das Gerüst der Anwendung erstellt und anschließend sofort Quelltext erzeugt, der dann mit Leben gefüllt wurde, ähnlich der Quelltexterzeugung des Formular-Designers. Wenn dort die UML-Listen separat gewartet werden müssen, beauftrage ich hiermit die Borlander, diesen Zustand umgehend zu ändern, noch vor Erscheinen von Delphi 2006.

schöni

[DGL-luke]

Zitat:

Zitat von Hansa

Delphi-Quellcode:

TRealEdit = class(TIntEdit)

procedure TRealEdit.KeyPress(var Key: Char);
begin
  inherited KeyPress(Key);  // nur 0..9 werden zugelassen, sonst :
  if (Key <> DecimalSeparator]) then  // hier auch noch , oder . zulassen
    key := #0;
end;

So wird das aber nichts... decimalseparator wurde ja schon im inherited genullt ;)

EDIT: am besten wäre hier wohl ein set of char, das mit allem, das erlaubt ist, befüllt wird. wobei dann das ganze ableiten hinfällig wird, wenn man dieses als feld deklariert und in der keypress-prozedur überprüft. ;)