Get/Set

finix

kingruedi schrieb:

Ich benutze die 2. Methode und finde nicht, dass diese verwirrt. Man wird ja als Programmierer schon den Unterschied zwischen
foo.kraft(1); //und
std::cout << foo.kraft() << std::endl;
erkennen. Wozu ich da extra get oder set vorschreiben sollte ist mir schleierhaft.

Was machst du wenn foo's kraft von etwas abhängig ist? Etwas was du erst übergeben musst?

Cocaine

Ist es denn dann noch eine Getter-Methode? Ich würd's dann eher calcForce() o.ä. nennen...

nman

finix schrieb:

Was machst du wenn foo's kraft von etwas abhängig ist? Etwas was du erst übergeben musst?

Was meinst Du?

Inwiefern sollte sich diese Methode dann von setKraft() oä unterscheiden?

finix

Cocaine schrieb:

Ich würd's dann eher calcForce()

Hm. Stimmt eigentlich. Aber trotzdem. Wenn du irgendwie mehrere Kräfte oder sonstwas hast und die über nen Index abfragen möchtest wirds auch kritisch.

nman schrieb:

Inwiefern sollte sich diese Methode dann von setKraft() oä unterscheiden?

Es ging um die Methode ohne Prefix.

junix

Helium schrieb:

Fuer alle variablen, die ich von aussen aendern muss/kann darf schreib ich setter ! Falsch ?

Klar erkannt. Falsch! Wenn du sie ändern musst, ok, aber wie oft kommt es vor, dass du direkt ein Attribut ändern musst. Wenn du Sie ändern kannst? Das kannst du immer. Schwachsinn. Darf? Du darfst es, sobald es eine Methode gibt, mit der du es machen kannst.

Äh hallo? irgendwie wird mir der Standpunkt hier nicht ganz klar. Ich bin absoluter Verfechter von Zugriffsmethoden. Und zwar konsequent auch für Attribute die nur klassenintern verwendet werden. Ich würde Shades Aussage eher umkehren: Das nicht verwenden von Set/Get-Methoden sollte mit Bedacht gewählt werden.

Wieso? Ganz einfach: Nur Get/Set Methoden garantieren mir, dass ich die Klasseninterna jederzeit beliebig umkrempeln und ergänzen kann, wies grad spass macht, ohne die ganzen Zugriffe auf das Objekt umbauen zu müssen.

Beispiel:
Ich habe ein Doc/View System mit den Klassen TmyDocument und TmyView. Beide gehören in einen Texteditor, wobei TmyView zur Anzeige des Textes in TmyDocument dient. TmyDocument stellt den Text in der Variable "MyText" zur Verfügung.

Nun wünscht man sich noch eine Möglichkeit definierte Revisionen zu erstellen. Um die Einfachheit der Bedieung sicherzustellen soll die Revisionskontrolle über ein weiteres Panel ermöglicht werden und an TmyView so wenig wie möglich rumgebaut werden.
Wo realisiert man nun sinnvoller Weise einen Revisionsspeicher? Innerhalb des Dokuments würde ich mal behaupten.

Wenn ich hier nun allerdings durch (fadenscheinige) Performance-Gründe die get-Methode (ebenso wie die Set-methode) spare, ist es mir nicht möglich, den Klasseninternen Speicher so umzubauen, dass ich zu guter Letzt nicht mind. 1 mal den Text doppelt im Speicher habe, weil ich ja die Revisionskontrolle habe, welche unter Umständen den zu speichernden Text speisen muss. Das erweiterte Interface? Kein Problem... was zum echten Problem wird ist der Zugriff auf MyText.... da kann ich nur um myText rumbauen und die Effizienz sinkt in den Keller. Wäre hier eine getter-Methode verwendet worden, hätte man ganz einfach die Methode so passend umgebaut, dass sie immer den gewünschten Revisionsstand zurückliefert.

... zugegeben ein konstruiertes Beispiel...vielleicht ist das Beispiel hier etwas naheliegender und entsprechend nachvollziehbarer:

Ich bau ne Anwendung mit ner Klasse XY welche ebenfalls irgendwelche Daten enthält welche sie für Berechnungen benötigt. Zunächst wird die Anwendung single-Threaded betrieben... Keine Synchronisationsprobleme, nix... Hauptsache Power.... also weg mit den 2-3 Takten die jeder Aufruf der Zugriffsmethode benötigt.
Nu kommts aber, dass eine weitere Anwendung gebaut wird, welche eigentlich auf die selbe Klasse zurückgreifen könnte, da sie die selben/ähnliche daten zu verarbeiten hat... diese Anwendung läuft allerdings blöderweise multithreaded... ...egal wird schon gehen.... nach tagelanger Problemsuche von sporadisch auftretenden Fehlern stehts fest: Synchronisationsprobleme.... tja.. was steht an? Umbau der zugreifbaren Variablen auf Zugriffsfunktionen welche CriticalSections verwenden... zack und schon muss ich meine 2. Anwendung - und natürlich auch die Erste um die Kompatibilität sicher zu stellen - umbauen.
Na dann danke.

Weitere Beispiele gefällig?

Ich hab noch ein paar auf Lager für all die, welche auf die Idee kommen "Set/Get-Funktionen brauchts ned" oder "sollten mit vorsicht eingesetzt werden". Was allerdings den Kern des Threads (wie man die Get/Set-Funktionen nun implementiert) angeht, muss ich sagen, dass ich alleine schon aus Gründen der Ordnung immer get/set voranstelle... Kostet mich ja nix und schafft eindeutige Verhältnisse.

So, und jetzt geh ich mal Asbestunterwäsche kaufen...

-junix

Asbest als atembare Fasern ist krebserregend.

Ich bin absoluter Verfechter von Zugriffsmethoden. Und zwar konsequent auch für Attribute die nur klassenintern verwendet werden.

warum aber zugriffsmethoden für attribute die nur klassenintern verwendet werden??????

das macht es keinen sinn,
es widerspricht dem kapselungsgedanken und verletzt ihn,
wenn es klassenintern ist warum soll dann bloss jemand von aussen überhaupt die möglichkeit haben etwas damit zu machen?,
es ist auch ein unnötiger und zusätzlicher aufwand

Wieso? Ganz einfach: Nur Get/Set Methoden garantieren mir, dass ich die Klasseninterna jederzeit beliebig umkrempeln und ergänzen kann, wies grad spass macht, ohne die ganzen Zugriffe auf das Objekt umbauen zu müssen.

wenn es für klasseninterna keine get/set methoden gibt, kann man sie noch viel besser umbauen und muss keine eigentlich sinnlosen methoden ändern

ich frage mich wieso überhaupt klasseninterna extern benutzbar sein sollten,
interna sind intern oder nicht?

extern sollten doch eher die möglichen aktionen sein

irgendwie kommen mir die klassen mit den ganzen get/set methoden mehr wie datenspeicher statt auf die problemlösung bezogene objekte vor,
es muss auch diese datenobjekte geben aber mit den get/set methoden wird jede klasse dazu

nman

finix schrieb:

Es ging um die Methode ohne Prefix.

Hilf mir auf die Sprünge, ich hab keine Ahnung was Du meinst.

finix schrieb:

Was machst du wenn foo's kraft von etwas abhängig ist? Etwas was du erst übergeben musst?

Was ist dann der Unterschied zwischen einem überladenen kraft() und setKraft()?

Jetzt wird aber ganz freakig. Ich bin generell gegen jegliche Verwendung von Klassen und auch gegen das schreiben von Funktionen außer der main-Funktion. Alle Variablen sollten direkt zu beginn definiert werden. So hab ich jederzeit follen zugriff auf alles. Und kann alles in jeder Situation genau so anpassen, wie ich es gerne hätte. Das nenne ich den Perfekten Programmierstil.

Walli

Jo, 1968 wars das auch.

Vellas

helium logged out schrieb:

Jetzt wird aber ganz freakig. Ich bin generell gegen jegliche Verwendung von Klassen und auch gegen das schreiben von Funktionen außer der main-Funktion. Alle Variablen sollten direkt zu beginn definiert werden. So hab ich jederzeit follen zugriff auf alles. Und kann alles in jeder Situation genau so anpassen, wie ich es gerne hätte. Das nenne ich den Perfekten Programmierstil.

*löl*
Klar und viel Platz sparen, also so viel in eine Zeile wie geht....

Code-Hacker

rüdiger

don't feed the trolls

DrGreenthumb

junix, niemand will get/set-Funktionen abschaffen und die Variablen public machen

Ging darum, dass viele get/set-Funktionen nicht viel besser als public-Variablen sind.
Beispiel: Statt player.setX(player.getX() + 10); sollte es lieber player.move() heißen, möglicherweise ein player, ganz ohne setX()-Funktion.

Aber irgendwie hat sich der Thread gewendet, ich glaube der Originalposter wollte nur wissen welche Namensgebung schöner ist.

Bashar

Ich verwende attr() und set_attr().

junix

bozo schrieb:

Ich bin absoluter Verfechter von Zugriffsmethoden. Und zwar konsequent auch für Attribute die nur klassenintern verwendet werden.

warum aber zugriffsmethoden für attribute die nur klassenintern verwendet werden??????

... Stichwort Ableitung/Vererbung ...

bozo schrieb:

es widerspricht dem kapselungsgedanken und verletzt ihn,

Den erkläre mir mal?

bozo schrieb:

Wieso? Ganz einfach: Nur Get/Set Methoden garantieren mir, dass ich die Klasseninterna jederzeit beliebig umkrempeln und ergänzen kann, wies grad spass macht, ohne die ganzen Zugriffe auf das Objekt umbauen zu müssen.

wenn es für klasseninterna keine get/set methoden gibt, kann man sie noch viel besser umbauen und muss keine eigentlich sinnlosen methoden ändern

? Äh ich weiss ja ned... aber wir sprechen hier nicht von einem wegschmeissen der alten Funktionalität welches nach aussen direkt Sichtbar wird...

In Anebtracht deines obigen Irrtums, erspare ich uns allen den Kommentar deiner weiterer Aussagen...

-junix

junix

DrGreenthumb schrieb:

junix, niemand will get/set-Funktionen abschaffen und die Variablen public machen

Da sah Shades Post allerdings etwas anders aus... hmmm

-junix

junix schrieb:

bozo schrieb:

warum aber zugriffsmethoden für attribute die nur klassenintern verwendet werden??????

... Stichwort Ableitung/Vererbung ...

Was hat das mit Vererbung zu tun? Btw, es gibt ja auch noch protected. Warum gleich public/getter/setter?

junix schrieb:

bozo schrieb:

es widerspricht dem kapselungsgedanken und verletzt ihn,

Den erkläre mir mal?

Was gibt es da bitte zu erklären? bozo hat völlig recht. Variablen, die du nur Klassenintern verwendest, gehen keinem was an.

junix

Auch Protected-Elemente sind Klasseninterne elemente ... oder etwa nicht?

-junix

junix

Vielleicht doch noch dazu ein Wort:

Optimizer schrieb:

junix schrieb:

bozo schrieb:

es widerspricht dem kapselungsgedanken und verletzt ihn,

Den erkläre mir mal?

Was gibt es da bitte zu erklären? bozo hat völlig recht. Variablen, die du nur Klassenintern verwendest, gehen keinem was an.

Inwiefern widerspricht das Verwenden von Zugriffsfunktionen dem Kapselungsgedanken? Ich kann nicht nur Variablen auf unterschiedliche Zugriffsebenen zu setzen...

-junix

@junix

Ich bin absoluter Verfechter von Zugriffsmethoden. Und zwar konsequent auch für Attribute die nur klassenintern verwendet werden.

da deine aussage etwas ungenau ist, kann man nur etwas deuten

das bedeutet ja eigentlich, dass die attribute wirklich nur für die verwendung in der klasse vorgesehen sind, und auch nur dort verwendet werden

warum dann zugriffsmethoden?

also falls die zugriffsmethoden public sind, ist es meiner meinung nach falsch, da sie dann von aussen benutzt werden können, aber die gehen diese daten garnichts an

falls die zugriffsmethoden private sind, ist es zuviel aufwand und sinnlos

falls die zugriffsmethoden protected sind und in einer abgeleiteten klasse benutzt werden und
a) (private daten) ist es eigentlich auch falsch, da die zugehörigen attribute ja nur zur basisklasse gehören bzw. ist es überhaupt sinnvoll, wenn die daten private in der baseclass sind, das die abgeleitete wirklich etwas damit machen kann
b) (protected daten) werden ja die attribute direkt vererbt, zuviel aufwand und sinnlos

... Stichwort Ableitung/Vererbung ...

auch ist deine aussage allgem. und nicht auf ableitung/vererbung speziell gerichtet

@Optimizer
genau, so sehe ich das auch