Eigene Objekte mit Properties

Ich habe gerade eine neue Stelle angenommen. Bisher habe ich hauptsächlich mit Visual Basic entwickelt und hatte dementsprechend wenig Kontakt zu eigenen Objekten mit eigenen Properties. Hier entwickle ich mit Delphi7.

Ich habe von Bekannten und Arbeitskollegen bisher immer gesagt bekommen, dass, wenn ich eine eigene Objektklasse definiere, sämtliche Kommunikation nur über Properties und Methoden laufen soll. Hier läuft es bisher etwas anders: Zwar werden spezielle Funktionen in einzelnen Klassen gekapselt, jedoch werden keine Propertydefinitionen verwendet, sondern die Variabeln stehen im public-Abschnitt der Units und können somit direkt editiert werden.

Meine Frage: Gibt es hierbei irgendwelche Nachteile, außer der nicht vorhandenen Möglichkeit einer direkten Prüfung des geänderten Wertes einer Variablen, bzw. dem automatischen Ausführen von bestimmten Aktionen bei Veränderungen des Wertes einer Variablen?

Vielleicht kurz zum Hintergrund. Derzeit wird diskutiert, wie weiter verfahren werden soll und ob in Zukunft der Mehraufwand durch die Verwendung von Properties gemacht werden soll. Ich suche nach Argumenten, die mir zu Begründen helfen, warum Property-Definitionen sinnvoller sind, als der direkte Variablenzugriff.

Freue mich über jedes Argument .

MfG. Patrique

Falls du mal eine Komponente aus deiner Klasse machen möchtest, brauchst du properties, wenn du möchtest, dass der User diese über den Objektinspektor editieren kann. (Bin mir jetzt aber nicht hundert pro sicher, hab noch keine Komponenten erstellt).

Mit properties kannst du einfach festlegen, ob die Variable Readonly ist oder ned.

Es ist auch einfacher und übersichtlicher, wenn man Properties verwendet. So sieht der, der das Objekt verwendet nur zum Beispiel objekt.text anstelle von setText und getText.

Mehr Programmierarbeit ist es ja nicht. Musst ja nur schreiben property blabla:integer; und dann complete class at cursor drücken und schon macht delphi für dich die arbeit ;-)

fazit: ich find properties cool und zudem noch nützlich

-

Benutze auf jeden Fall Eigenschaften für den Zugriff auf Klassen-Atribute. Erstens widerspricht der direkte Zugriff auf die Atribute den OOP-Prinzipien, zweitens hast du keine Überprüfung des Wertes, den du schreiben willst.

Und wie schon gesagt, bei Komponenten laufen alle Einstellungen über Eigenschaften ( insbesondere die lese- und schreibrechte ).

hmm,

public Variablen die die Eigenschaften einer Klasse representieren sind ein frevel an der OOP an sich. Eine Property/Eigenschaft legt ja was bestimmtes fest. zB. den Typ eines Objekts. Wenn jetzt Hinz und Kunz diese Eigenschaft einfach verändern können, dann ist dies Schwachsinn und eine Potenzielle Fehlerquelle !

Ein kleines Beispiel hierzu. Ich hab mir ne kleine Klasse gebastelt für die Automation von Open Office Documenten von Delphi aus. Da gibt es eine Property die anzeigt welchen Typ das geöffnete Objekt hat, Writer, Calc etc. , denn man kann eben nicht auf Zellen eines Kalulationssheets zugreifen wenn man ein Textdokument geöffnet hat. Wenn diese Property jetzt einfach als public Variable da wäre, lol, dann könnte ich einfach Fehlermeldungen produzieren ohne mich anzustrengen

Das hört sich ja alles schön und gut an, aber wie argumentierst du denn, wenn du eine interne Klasse hast, die du selber entwickelt hast und die nur innerhalb deiner eigenen Anwendung(en) verwendet wird?

Du musst wissen, dass es für mich keine Frage darstellt, ob ich 'echte' Properties verwende, oder nicht, da sie zu den ersten Dingen gehören, die ich über Bücher und Workshops zu OOP / Delphi gelernt habe. Die Schwierigkeit besteht für mich nur darin, meine Kollegen davon zu überzeugen, in recht großen Projekten von der alten und bisher gut funktionierenden Variante Abstand zu nehmen und in Zukunft korrekte Property-Definitionen mit read/write einzusetzen.

Hoi!

Erstmal um ein paar Gegenargumente aus dem Weg zu räumen, die Möglicherweise von deinen Kollegen kommen könnten:

- Properties brauchen imho zum lese nicht mehr Zyklen als öffentliche Felder (wenn sie über einen direkten Schreibzugriff verfügen, brauchen sie dort auch nicht mehr Zyklen)
- Properties lassen sich mindestens ebenso schnell implementieren wie öffentliche Felder. Einziger unterschied: vor das Feld gehört ein "property" Schlüsselwort und danach ist einmal Strg + Shift + C zu drücken.
- Hätte man seit beginn der Programmierung "der Gewohnheit" wegen nichts verändert, so würde man heut noch immer nur in Assembly Sprachen Programmieren.

Ein paar Argumente die eindeutig für das Verwenden der Properties sprechen:
- In der OOP ist das größte Tabu öffentlich, direkten Schreibzugriff auf Felder zu geben (egal ob die Klassen nur Bibliotheksintern benutzt werden). Selbst die Eigenschaften keine Eingabeüberprüfung benötigen und sowohl Schreib als auch Lesezugriff auf diese besteht sollte auf ein Property zurückgegriffen werden, um evtl später einfach eine Eingabeprüfung oä noch nachzurüsten und um den Prinzipien der Objektorientierung gerecht zu werden (Eigenschaften nur über Zugriffsmethoden [in diesem Fall ist das Property mit Lese und Schreibroutinen vergleichbar]).
- Felder, die eigentlich Read Only sein sollten können nun auch fest als solche deklariert werden. Es kann nun nichtmehr aus versehen ein Wert in ein Feld geschrieben werden, der evtl zu schweren Programmfehlern / Fehlverhalten der Klasse führen kann. Dieser falsche Zugriff auf die Klasse kann sowhl außerhalb als auch innerhalb des Hauses / Firma zu verwirrungen und verlusten führen! Ein Read-Only Property schließt dieses potentielle Finanzloch.
- Sollte sich aus irgend einem Grund bei der weiterentwicklung einer Klasse herausstellen, dass ein Wert, vor der Ausgabe aus der Klasse noch manipuliert werden muss, was vorher nicht nötig war, so muss das Öffentliche Feld durch eine Lesemethode und eine Schreibmethode ausgetauscht werden und alle stellen, an denen in das Feld geschrieben wurde bzw aus ihm gelesen dementsprechend aktuallisiert werden. Einem Property jedoch ist es egal, ob es als read und write Identifier nun eine Methode oder ein Privates Feld hat. Das austauschen von direktem Feldzugriff und Lese-/Schreibmethode erfolgt ohne anderen Quelltext aktuallisieren zu müssen. Dies veringert deutlich den Arbeitsaufwand und spart Finanzmittel.

Es gibt warscheinlich noch einige Weitere Argumente, aber wie man sieht, ob aus wirtschaftlicher oder aus technischer Sicht: Properties bringen viele Vorteile mit sich und viele Vorurteile sind und bleiben schlicht Vorurteile.

In der Hoffnung dir beim Überzeugen deiner Kollegen geholfen zu haben,

..ooOOipOOoo..

PS: Und du kannst deinen Kollegen sagen, dass selbst ein Schüler über ihre öffentlichen Felder schmunzeln musste ;D

hmm,

Original geschrieben von patrique
aber wie argumentierst du denn, wenn du eine interne Klasse hast, die du selber entwickelt hast und die nur innerhalb deiner eigenen Anwendung(en) verwendet wird?

Zum Vergrößern anklicken....

Mit gutem Stil ? Und damit dass man es einfach verinnerlicht, denn nicht jede Bib wird intern sein.