OOP Frage

[kurtm1]

Habe mir ein paar Beispiele zur OOP angesehen, und dabei ist folgende Frage aufgetreten:

Also es wir ganz normal eine Klasse deklariert, die bei den private Deklarationen einige Methoden hat. Diese Methoden geben nur ein einfachen Zahlenwert zurück. Bei den Public Deklarationen gibts dann einige properties, die bei "Read" dann die Methoden der Private Deklarationen aufrufen.

Was macht das für einen Sinn über eine Variable den Funktionswert zu bekommen, und nicht direkt die Funktion aufzurufen?

[markusj]

Du kannst umgekehrt auch Werte setzen Lassen, und dabei evtl. ungültig gewordene Werte in der Instanz gleich löschen.
Asonsten müsstest du zuerst den Wert setzen und dann eine womöglich private prozedur/funktion aufrufen.
Mal ganz davon abgesehen, dass du so die Möglichkeit hast, Werte einfach zu locken indem du sagst, wird nicht mehr beschrieben.

mfG

Markus

EDIT: Oder umgekehrt den Zugriff auf die Variable zu verbieten, solange intern an ihr Gearbeitet wird ...

[mkinzler]

Doe Properties werden nur deklariert um im OI angezeigt zu werden, so daß man sie hierüber manipulieren kann.

[kurtm1]

Das mit dem Werte reinschreiben ist klar, aber wenn ich für eine property nur read habe, zahlt sich das ja nicht aus oder?

[Hawkeye219]

@mkinzler

Dazu müßten sie aber im published-Bereich stehen. :wink:

Gruß Hawkeye

[tigerman33]

Properties sind der OOP-Weg auf die Eigenschaften (wie der Name schon vermuten lässt), sprich den Status der Instanz zuzugreifen. Direkte Feldzugriffe von außerhalb des Objekts sollten vermieden werden und stattdessen über Properties gekapselt werden. Da gewisse Aspekte dieses Objektstatus sich aber ja zur Laufzeit sehr dynamisch ändern können, gibt es die Möglichkeit mit den Gettermethoden den entsprechenden Wert quasi "on-demand" zu berechnen.

[sakura]

Um zur Abwechslung mal Deine Frage zu beantworten. Wenn es um das LEsen einer Eigenschaft geht und Du nur einen Wert eines vorhandenen Feldes zurückgeben willst, dann kannst Du dieses Feld direkt bei read eintragen und brauchst dafür keinen extra "Getter". Alles andere ist OOP-Puristik und Geschmackssache.

...:cat:...

P.S.: Aber der Titel Deiner Frage könnte schon aussagekräftiger sein :zwinker:

[Neutral General]

Hi,

Also hier ist mal mein Lieblingsbeispiel.

Delphi-Quellcode:

TBeispiel = class
 private
  FLeben: Integer;
  FTot: Boolean;
  function GetLeben: Integer;
  function SetLeben(const Value: Integer);
 public
  property Tot: Boolean read FTot;
  property Lebensenergie: Integer read GetLeben write SetLeben;
 end; 

function TBeispiel.GetLeben: Integer;
begin
 Result := FLeben; 
 { Ob nicht einfach Read FLeben reicht darüber kann man sich in dem Beispiel streiten^^}
end;

procedure TBeispiel.SetLeben(const Value: Integer);
begin
 if Value > 0 then // Wenn HP > 0
  FLeben := Value // Dann FLeben auf neuen Wert setzen
 else
 if Value <= 0 then // Wenn HP <= 0 
 begin
  FLeben := 0;     // Dann FLeben auf 0 setzen
  FTot := true;   // und die Einheit als Tot erklären
 end;
end;

Damit kann man relativ gut erkennen wofür Properties gut sind. In der Set-Methode wird nicht einfach nur der neue Wert gesetzt (Dann könnte man theoretisch ja auch einfach nur Variablen benutzen) sondern es wird je nach Situation anders gehandelt.
Beispiel 1b:

Delphi-Quellcode:

var Test: TBeispiel;

procedure Ka;
begin
 Test := TBeispiel.Create;
 if not Test.Tot then ShowMessage('Einheit lebt noch!');
 Test.Leben := -10;
 ShowMessage('Lebensenergie: ' + IntToStr(Test.Leben));
 if Test.Tot then ShowMessage('Einheit ist tot!');
end;

Wie du siehst musstest du nirgendwo Test.Tot := true setzen. Was auch nicht gehen würde weil es eine Readonly-Property ist.
Ich hoffe du hast jetzt verstanden wie das funktioniert und was für Vorteile sich daraus ergeben. Und ich hoffe ich habe die Frage richtig verstanden und das hier nicht umsonst geschrieben :mrgreen:

Gruß
Neutral General

[tigerman33]

Wofür ist das Feld FTot gut? :gruebel: Warum nicht einfach so:

Delphi-Quellcode:

private
  ...
  function GetTot: Boolean;
public
  property Tot: Boolean read GetTot;
  property Lebensenergie: Integer read GetLeben write SetLeben;
end;

...
function TBeispiel.GetTot: boolean;
begin
  Result := Lebensenergie = 0;
end;

//edit:
Da sieht man ja auch gleich ein gutes Beispiel für eine Gettermethode.

// 2. edit:
Wobei die ursprüngliche Frage damit natürlich nicht gelöst ist--eine public Funktion würde es ja genauso tun...

[Der_Unwissende]

Zitat:

Zitat von tigerman33

Wobei die ursprüngliche Frage damit natürlich nicht gelöst ist--eine public Funktion würde es ja genauso tun...

Hi,
natürlich tut es eine Kombination von öffentlichen Gettern und Settern auch. Das man komplett ohne Properties auskommt, zeigt z.B. Java, auch hier gibt es im BDK einen Property Editor, der kommt nah an den Objektinspektor ran, verwendet aber keine direkten Properties. [OT] Der parst einfach nur, ob es zu einer Variablen Methoden mit der Bezeichnung "setVariablenname" oder "getVariablenname" existieren [/genug OT]

Jedenfalls gibt es kein Muss für properties. Sie können einfach verwendet werden, weil es nun mal schöner ist auf eine Variable zuzugreifen. Wenn ich setVar und getVar habe, so sind dies zwei verschiedene Methoden, ich muss also je nachdem ob ich lesen oder schreiben möchte die richtige Methode verwenden. Verwendet man properties, so kann man halt ein und den selben Bezeichner sowohl zum Lesen als auch Schreiben verwenden.

Ob das nun die Rechtfertigung ist oder nicht, darüber lässt sich sicherlich streiten, aber das muss ja nicht sein. Immerhin bleibt jedem die freie Wahl was er präferiert.

Gruß Der Unwissende