An die OOP-Profis bezüglich Ableitung und protected Variablen/Methoden

[icemanemp]

Hi,

hatte gestern zufällig bei einem Arbeitskollegen über den Codegeschaut, da er ein Fehler gesucht hat und einen 2ten Mann wollte, der im kurz hilft.

Da hab ich ihn angefahren, warum er seine Variablen im private-Teil deklariert und um in abgeleiteten Klassen darauf zuzugreifen dann eine property macht (Delphi) das im protected-Teil steht.
Für nicht Delphiainer: er macht Set/Get-Methode im protected-Teil und die Variable dazu im privat?

Ich hab bisher immer meine Modele per Modelmaker gemacht und dort einfach die Variable direkt in den protected-Teil!
Ich hab mir kurz darüber gedanken gemacht, was ein Property bzw. Get-Methode für Voteile hat:
Man könnten, wenn man beim Property das write weglässt oder die Set-Methode eben, verhindern das nur gelesen wird z.B. bei Objekten sinnvoll, das jemand anderes der ableitet nicht das Objekt neu intialisiert...

Sonst sind mir keine Vorteile eingefallen.

Mich würde jetzt interessieren, wie ist die korrekt Vorgehensweise? Gibt es da in der OOP-Denkweise ein festgelegte Vorgehensweise oder ist in diesem Fall jedem Programmierer freigestellt was er tut? Was findet ihr besser und warum? Nachteile/Vorteile?

[noid]

die getter und setter machen es besser, da sich ja unter umständen die klasse selbst ändert, aber die schnittstelle nicht (siehe modularisierung). wenn dann eine andere klasse direkt auf eine member-variable zu greift, die nicht mehr existiert -> problem, viel umschreiben. über die schnittstelle ist das ganze gut gekapselt und die kannst leicht den wert aus anderen berechnen, oder andere dinge damit anstellen.

getter & setter -> pflicht. (eigentlich kann so gut wie jede gute ide die methoden automatisch erstellen)

[HellHorse]

wenn dann eine andere klasse direkt auf eine member-variable zu greift, die nicht mehr existiert -> problem, viel umschreiben.
Muss nicht einmal eine andere Klasse sein, kann sogar die sein, in der die Instanzvariable definiert ist. Von dem her gehöre auch in der `Zugriff auf Instanzvariablen immer nur über Accessoren (ausser in den seltenen Ausnahmen)'-Schule an.
Aber wie auch immer man es macht, es sollte vor allem konsistent sein. Das heisst immer Accessor, oder nie (in der Klasse oder Subklassen, nach aussen selbstverständlich immer).

[noid]

mit ner guten IDE ist das ja auch alles kein problem.

[Senior Sanchez]

Hi,

hatte gestern zufällig bei einem Arbeitskollegen über den Codegeschaut, da er ein Fehler gesucht hat und einen 2ten Mann wollte, der im kurz hilft.

Da hab ich ihn angefahren, warum er seine Variablen im private-Teil deklariert und um in abgeleiteten Klassen darauf zuzugreifen dann eine property macht (Delphi) das im protected-Teil steht.
Für nicht Delphiainer: er macht Set/Get-Methode im protected-Teil und die Variable dazu im privat?

Ich hab bisher immer meine Modele per Modelmaker gemacht und dort einfach die Variable direkt in den protected-Teil!
Ich hab mir kurz darüber gedanken gemacht, was ein Property bzw. Get-Methode für Voteile hat:
Man könnten, wenn man beim Property das write weglässt oder die Set-Methode eben, verhindern das nur gelesen wird z.B. bei Objekten sinnvoll, das jemand anderes der ableitet nicht das Objekt neu intialisiert...

Sonst sind mir keine Vorteile eingefallen.

Mich würde jetzt interessieren, wie ist die korrekt Vorgehensweise? Gibt es da in der OOP-Denkweise ein festgelegte Vorgehensweise oder ist in diesem Fall jedem Programmierer freigestellt was er tut? Was findet ihr besser und warum? Nachteile/Vorteile?


Funktioniert das denn, ne private deklarierte Variable mit protected Memberfunktionen (also Getter/Setter)? Zumindest inner Ableitung könnte es doch schwierig werden, sobald man die getter/setter überschreibt, oder? Weil die hätten nicht mehr den Zugriff auf diese Variable.
Wirds dagegen nicht überschrieben dürfte das ganze funktionieren, aber eventuell wäre es ratsam die getter/setter als konstant zu deklarieren, sodass sie nicht überschrieben werden können.

Also ansich stellt das eigentlich kein Problem dar. Er will halt diese Variable explizit von Zuweisungen außerhalb des aktuellen Objektes schützen, aber vllt braucht ja noch ne Unterklasse Zugriff auf die Variable, deswegen halt protected getter/setter.

[icemanemp]

Super. Ihr habt recht! Sinnvoller ist es!
Könnte dann z.B. im Get, wenn Objekt nicht vorhanden dieses initialiseren und müsste das nicht im Konstruktor der Klasse machen!
Bei Variablen wie schon gesagt entweder wo anders her holen oder ein Defaultwert beim Get machen!

@Senior Sanchez
Nur per inherited (Aufruf der GetMethode des Vorfahrens) kannste auf den Wert zugreifen! Aber wenn im Vorfahren eben Defaultwerte ausgegeben werde usw. du aber wirklich den ursprungswert möchtest, dann haste ein Problem, das man nur mit weitern Methoden lösen könnte.

Naja, dann werde ich die nächsten Klassen bissel anders gestalten! Meine vorhandenen lass ich mal so, erst wenn ich wieder ne grösse Änderung mache oder Refactoring meiner eigenen Programme. Mein Chef oder der Projektleiter hauen mir die Software ja um die Ohren, wenn was net funktioniert im Ständen die bald zum Kunden kommen...

[Senior Sanchez]

@Senior Sanchez
Nur per inherited (Aufruf der GetMethode des Vorfahrens) kannste auf den Wert zugreifen! Aber wenn im Vorfahren eben Defaultwerte ausgegeben werde usw. du aber wirklich den ursprungswert möchtest, dann haste ein Problem, das man nur mit weitern Methoden lösen könnte.

Jo, sage ich doch, oder? Naja, ich glaube ich habe das Problem net so ganz verstanden, um was es hier ging *g*
Ist auch egal :) Freut mich dass jetzt aber Klarheit herrscht.

[Monger]

Super. Ihr habt recht! Sinnvoller ist es!
Könnte dann z.B. im Get, wenn Objekt nicht vorhanden dieses initialiseren und müsste das nicht im Konstruktor der Klasse machen!
Bei Variablen wie schon gesagt entweder wo anders her holen oder ein Defaultwert beim Get machen!


Vorallem kannst du Typwandlungen auf die Weise durchführen!

Ein Fall der mir einige Male über den Weg gelaufen ist: angenommen du hast eine Liste mit Personen (meinetwegen Mitarbeiter o.ä.). Dein gesamtes Programm ist darauf ausgelegt, sich Personen aus dieser Liste zu schnappen und zu bearbeiten.

Jetzt fällt dir siedend heiß ein: Die Datenstruktur reicht nicht! Deine Personen sollen mit irgendwas assoziert werden (meinetwegen den Firmenwagen), und du musst genau an dieser Stelle deine Struktur umschmeißen.
Du baust also eine neue Liste auf, die nicht nur deine Mitarbeiter, sondern auch die Firmenwagen enthält. Jeder Programmteil, der jetzt bei diesem Attribut eine Person erwartet, kriegt jetzt etwas völlig unverständliches.

Solche Wandlungen kannst du im getter hervorragend machen. Dein Attribut wird erweitert, aber statt alle Zugriffe auf das Attribut zu ändern, änderst du nur den Getter.

[Xmas]

Funktioniert das denn, ne private deklarierte Variable mit protected Memberfunktionen (also Getter/Setter)? Zumindest inner Ableitung könnte es doch schwierig werden, sobald man die getter/setter überschreibt, oder? Weil die hätten nicht mehr den Zugriff auf diese Variable.
Wirds dagegen nicht überschrieben dürfte das ganze funktionieren, aber eventuell wäre es ratsam die getter/setter als konstant zu deklarieren, sodass sie nicht überschrieben werden können.
Du brauchst dann ja nicht den Zugriff auf die private-Variable, sondern nur den Zugriff auf die Accessoren der Oberklasse.

Da lob ich mir doch die Properties von C#. Denn Variablen durch Properties zu ersetzen erfordert keine Änderung im darauf zugreifenden Code.

[SgtTynis]

Properties haben zu dem den Vorteil Multithreadsicherheit fuer eine Instanz zu gewaehrleisten bzw. diese so zu programmieren das sie gewaehrleisten werden kann, was beim direkten Zugriff auf die Membervariable nicht der Fall ist.

[Senior Sanchez]

Du brauchst dann ja nicht den Zugriff auf die private-Variable, sondern nur den Zugriff auf die Accessoren der Oberklasse.

Da lob ich mir doch die Properties von C#. Denn Variablen durch Properties zu ersetzen erfordert keine Änderung im darauf zugreifenden Code.

*disch*
Stimmt ja ;) War da gerade etwas geistesabwesend *g*