Get/Set

[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

[Gast]

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

[bozo]

@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

[junix]

bozo schrieb:

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

Was ist daran ungenau?

bozo schrieb:

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

Klasseninterne attribute? Klassenintern bedeutet für mich: protected oder private.

warum dann zugriffsmethoden?

Gemäss obiger Definition existieren folgende Zugriffsmöglichkeiten:

• Innerhalb abgeleitete Klassen
• Andere Klassenmethoden

Damit schliesst sich allerdings nicht aus, dass ein Attribut durch eine oder mehrere public-Methoden verändert/gelesen werden kann. Zwar nicht direkt aber jederzeit indirekt durch die public-Methoden.

also falls die zugriffsmethoden public sind, ist es meiner meinung nach falsch

Wieso impliziert für dich "zugriffsmethode" automatisch "public"?

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

Siehe oben.

den Rest lasse ich hier auch wieder weg, da durch obige Ausführungen beantwortet.

-junix

[junix]

Etwas habe ich vergessen. Ich glaube dieses Zitat ist eine weitere Ausführung wert:

bozo schrieb:

b) (protected daten) werden ja die attribute direkt vererbt, zuviel aufwand und sinnlos

Genau mit dieser Haltung machst du dich selber dessen Schuldig, was du mich vorhin bezichtigt hast: Die Verletzung des Kapselungsgedanken. Denn, vererbst du Attribute direkt, kannst du die Basisklasse ebenfalls nichtmehr nach deinen Ideeen umbauen, ohne die erben der Klasse zu belasten...

-junix

[bozo]

@junix

Was ist daran ungenau? ... Wieso impliziert für dich "zugriffsmethode" automatisch "public"?

du schriebst ja nicht wer diese zugriffsmethoden nutzen darf,
also ist alles möglich, auch das sie public sind

Und zwar konsequent auch für Attribute die nur klassenintern verwendet werden.

das bedeutet nicht nur einfach wie die c++ syntax benutzt wird (public, protected oder private),
in deinem satz ist eine aussage über die art der verwendung der daten,
"nur klassenintern verwendet",
und genau darum geht es hier,
es geht um diesen anwendungsfall,
und hier sind die zugriffsmethoden falsch bzw. sinnlos,
eigentlich sollte ausser der benutzenden klasse niemand diese internen attribute kennen, ganz zu schweigen von einer nutzung

die ganze sache wegen vererbung sollte sich ja nur auf die attribute beziehen, die auch für eine vererbung gedacht sind, und nicht auf interne attribute der basisklasse, diese sind nur für die basisklasse gedacht und sonst für niemanden

wie man nun diese zur vererbung gedachten attribute benutzt, ist wohl sehr stark von den genauen umständen abhängig,
also ob man sie per protected direkt vererbt oder, wie du es willst, sie in der basisklasse private macht und protected zugriffsmethoden benutzt

[bozo]

junix schrieb:

warum dann zugriffsmethoden?

Gemäss obiger Definition existieren folgende Zugriffsmöglichkeiten:

• Innerhalb abgeleitete Klassen
• Andere Klassenmethoden

...

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

Siehe oben.

das würde ja im falle einer nicht vererbenden klasse bedeuten,
dass du zugriffsmethoden für ein klasseninternes attribut in den anderen klassenmethoden benutzt statt es direkt zu verwenden???
das macht keinen sinn

eine klasse sollte ja wohl in ihren methoden ihre attribute auch benutzen können

wenn der direkte zugriff auf dieses attribut gekapselt sein soll, ist eine eigene klasse mit eigenen methoden angebracht, anstatt zugriffsmethoden in einer das attribut benutzenden klasse zu schreiben

[junix]

bozo schrieb:

Was ist daran ungenau? ... Wieso impliziert für dich "zugriffsmethode" automatisch "public"?

du schriebst ja nicht wer diese zugriffsmethoden nutzen darf,
also ist alles möglich, auch das sie public sind

Stimmt. Ich spezifiziere nicht näher. Das kann also ebenso bedeuten, dass sie private oder protected sein können.

bozo schrieb:

Und zwar konsequent auch für Attribute die nur klassenintern verwendet werden.

das bedeutet nicht nur einfach wie die c++ syntax benutzt wird (public, protected oder private),

Die Tatsache, dass wir hier im C++ Forum sind, impliziert schicht, dass wir hier über C++ reden. Entsprechend kommen auch die C++-Syntax-Elemente zum Zug.

bozo schrieb:

in deinem satz ist eine aussage über die art der verwendung der daten,
"nur klassenintern verwendet",
und genau darum geht es hier,
es geht um diesen anwendungsfall,
und hier sind die zugriffsmethoden falsch bzw. sinnlos,
eigentlich sollte ausser der benutzenden klasse niemand diese internen attribute kennen, ganz zu schweigen von einer nutzung

Wieso willst du einer abgeleiteten Klasse verbieten attribute einer Klasse die public nicht direkt beeinflussbar sind aber protected verfügbar, zu verändern?

bozo schrieb:

die ganze sache wegen vererbung sollte sich ja nur auf die attribute beziehen, die auch für eine vererbung gedacht sind, und nicht auf interne attribute der basisklasse, diese sind nur für die basisklasse gedacht und sonst für niemanden

Hallo?!? Wieso sollte ein Erbe einer Basisklasse keine Attribute seiner Parent-Klasse verändern dürfen?

bozo schrieb:

wie man nun diese zur vererbung gedachten attribute benutzt, ist wohl sehr stark von den genauen umständen abhängig,
also ob man sie per protected direkt vererbt oder, wie du es willst, sie in der basisklasse private macht und protected zugriffsmethoden benutzt

Eben nicht! Aus en selben Gründen wieso man keine Public-Variablen verwenden sollte.

Erklär mir eines: Wieso versuchst du krampfhaft die Tatsache, dass du einfach nicht zu Ende gedacht hast damit zu verbergen, dass du krampfhaft neue Argumente verweigerst?

-> Ich mag mich nichtmehr in immer neuen Varianten wiederholen
-> Ich mag nicht immer wieder Erkärungen abgeben, nur weil du nicht bereit bist über meine Aussagen länger als 2 sekunden nachzudenken

-junix

[junix]

bozo schrieb:

das würde ja im falle einer nicht vererbenden klasse bedeuten,
dass du zugriffsmethoden für ein klasseninternes attribut in den anderen klassenmethoden benutzt statt es direkt zu verwenden???

richtig.

bozo schrieb:

das macht keinen sinn

Wieso?

bozo schrieb:

eine klasse sollte ja wohl in ihren methoden ihre attribute auch benutzen können

Wer verbietet das? Es ist ja nur eine Ebene eingeschaltet, die z.B. Threadsicherheit ermöglicht... Das ist das was ich schon die längste Zeit sagte und mit meinem Beispiel zu sagen versuchte.

bozo schrieb:

wenn der direkte zugriff auf dieses attribut gekapselt sein soll, ist eine eigene klasse mit eigenen methoden angebracht, anstatt zugriffsmethoden in einer das attribut benutzenden klasse zu schreiben

DAS macht nun wirklich keinen Sinn.

-junix

[bozo]

Die Tatsache, dass wir hier im C++ Forum sind, impliziert schicht, dass wir hier über C++ reden. Entsprechend kommen auch die C++-Syntax-Elemente zum Zug.
...
Wieso willst du einer abgeleiteten Klasse verbieten attribute einer Klasse die public nicht direkt beeinflussbar sind aber protected verfügbar, zu verändern?

LOL

c++ syntax ist aber nur ein mittel, darüber gibt es noch eine designebene,
und darauf bezieht sich diese ganze sache,
nochmal:

Und zwar konsequent auch für Attribute die nur klassenintern verwendet werden.

wenn etwas nur klassenintern verwendet wird (designebene), dann ist es nur für die klasse gedacht und für niemanden anders, punkt,
wieso ich einer abgeleiteten klasse verbieten will diese attribute zu verwenden? ganz einfach weil es deiner (design)aussage entspricht!

ist es denn wirklich so schwer zu verstehen???

[quote]Hallo?!? Wieso sollte ein Erbe einer Basisklasse keine Attribute seiner Parent-Klasse verändern dürfen?[quote]

wenn diese attribute nicht für ihn gedacht sind, sondern nur für die basisklasse intern, dann soll er es auch nicht!
ich denke du bist für kapselung!
man kann daten nicht nur kapseln indem man den zugriff darauf mit zugriffsmethoden einschränkt sondern auch indem man die kompletten zugriff verbietet, z.b. private und keine zugriffsmethoden
du springst echt zw. beiden arten hin und her, mal so und mal das gegenteil

Eben nicht! Aus en selben Gründen wieso man keine Public-Variablen verwenden sollte.

eben nicht!
es hängt in erster linie davon ab was man und wie man etwas machen will,
auch public variablen bzw. structs haben bei einigen anwendungsfällen ihren sinn, hier eine ausage von Bjarne Stroustrup:

Yes. If every data can have any value, then it doesn't make much sense to have a class. Take a single data structure that has a name and an address. Any string is a good name, and any string is a good address. If that's what it is, it's a structure. Just call it a struct. Don't have anything private. Don't do anything silly like having a hidden name and address field with get_name and set_address and get_name and set_name functions. Or even worse, make a virtual base class with virtual get_name and set_name functions and so on, and override it with the one and only representation. That's just elaboration. It's not necessary.

du solltest echt mal seinen artikel lesen: http://www.artima.com/intv/goldilocks3.html
warum bist du bloss so fundamentalistisch in deinen ansichten

Erklär mir eines: Wieso versuchst du krampfhaft die Tatsache, dass du einfach nicht zu Ende gedacht hast damit zu verbergen, dass du krampfhaft neue Argumente verweigerst?

-> Ich mag mich nichtmehr in immer neuen Varianten wiederholen
-> Ich mag nicht immer wieder Erkärungen abgeben, nur weil du nicht bereit bist über meine Aussagen länger als 2 sekunden nachzudenken

wer sich hier verweigert ist ja wohl klar
du bringst ja keine neuen argumente sondern, wie du ja selbst schreibst, wiederholst dich immer in neuen varianten,
um was es wirklich geht verstehst du einfach nicht, im gegensatz zu manchem anderen hier,
du solltest wohl besser mal etwas länger nachdenken, bevor dir dann nur noch übrigbleibt, dich auf so eine verbale ebene zu begeben

richtig.
Wieso?
Wer verbietet das? Es ist ja nur eine Ebene eingeschaltet, die z.B. Threadsicherheit ermöglicht... Das ist das was ich schon die längste Zeit sagte und mit meinem Beispiel zu sagen versuchte.

du hast es auch hier nicht verstanden,
es ging und geht um deine ursprüngliche aussage, punkt,
und die ist sehr allgem. gehalten,
und in dieser allgemeinheit stimmt sie einfach nicht,
wenn du jetzt spez. bedingungen z.b. threadsicherheit mit einbeziehst ist das aber wieder etwas anderes, aber darum ging es nicht, dies ist eine weiterführende sache, und keine die du als begründung herbeiziehen kannst für deine ursprüngliche aussage,
bei grossen teilen von projekten und code ist aber einfach deine ursprüngliche aussage falsch und sinnlos

[Shade Of Mine]

junix schrieb:

DrGreenthumb schrieb:

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

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

Nein. Ich habe nur gesagt man soll getter/setter wohl überlegt eingesetzt werden sollen. Das man keine public Variablen hat, davon gehe ich mal aus.

Ich meinte es wie in einem Beispiel das hier schon gepostet wurde:

statt
player.setX(5);
sollte man uU lieber ein
player.move(1, FRONT);

oder so...

Ich meinte eigentlich, dass man die Zugriffe auf Variablen wohl überlegt anbieten soll. Public Variablen würde ich nie verwenden(es sei denn es macht Sinn). Und getter/setter sollten überlegt eingesetzt werden. Das führt dazu, dass der Zugriff auf Membervariablen eingeschränkt wird.

Und genau das meinte ich.

Sorry, wenn es nicht klar geworden ist.

Ich dachte, dass wir keine Public Variablen haben ist Voraussetzung...

[junix]

@Shade: Ok, dann habe ich dich falsch verstanden (o; Wobei ich der festen überzeugung bin, dass move() implizit setX und setY aufrufen sollte. Oder nicht?

@bozo: Mir reichts. Letztlich liegt sowieso vieles in den Händen und dem Ermessen des Programmierers. Nur bewegen sich in dem Fall einige Lösungen nicht auf der Sicheren Seite sondern auf der Grenze. Hier im Forum kann man allerdings schlecht abschätzen in wieweit sich das Gegenüber der Risiken bewusst ist, welche man mit einer Lösung eingeht. Entsprechend sollte man einen Lösungsweg favorisieren, mit dem man sich auf der sicheren Seite bewegt. Du wirfst mir vor ich sei fundamentalistisch? Gut. Ich bin fundamentalistisch, richtig. Und zwar vertrete ich wehement Lösungen welche sich auf der sicheren Seite bewegen. Es gibt genug bastelsoftware die scheisse baut, nur weil der Programmierer sich der Konsequenzen dessen, was er implementiert hat nicht bewusst ist. Du bist allerdings nicht minder fundamentalistisch, wenn du dich auf Struppi stützt in deiner Argumentation... Auch Struppi hat nicht überall recht.

Du laberst hier was von design ebene. Schön Gerade zur Design-Zeit sollte man sich doch auch die Optionen für die Zukunft offen halten? Leider hat noch kaum jemand wirklich vorhersagen können, was die Zukunft bringt. Entsprechend weisst du nicht wo dein Objekt später wiederverwendet wird...

Aber weisst du was? Was laber ich hier eigentlich... du hast recht. Ich lieg komplett falsch.
So, nu hat die diskussion ein Ende. Ich mag nicht mehr und ich will nicht mehr... Das ganze hier artet sowieso nur darin aus, dass du kläglich versuchst deine erste intervention zu rechtfertigen. ("*räbääää* deine Aussage war ungenau *räbää* ich hab mich geirrt *räbäää* aber ich kann doch nix für... drum muss ich jetzt irgendwie das 2 aufm Rücken loswerden.")

Schau: Ich habe mein Lehrgeld bezahlt was Zugriffsmethoden, geänderte Anforderungen und unvorhergesehene Fälle betrifft und wage mich - als gebranntes Kind - nur noch mit Asbestwäsche ins Feuer... Was du machst ist mir ehrlich gesagt egal. Aber Proklamiere hier nicht irgendwelche Semi-professionellen Lösungen von denen du weisst, dass sie unter bestimmten Umständen - die du nicht ausschliessen kannst - Fehlerhaft sein können.

Das war mein letztes Statement zu deinem Gebrabel hier.

-junix

[junix]

-überzählig-

[junix]

-zuviel-

[Shade Of Mine]

junix schrieb:

@Shade: Ok, dann habe ich dich falsch verstanden (o; Wobei ich der festen überzeugung bin, dass move() implizit setX und setY aufrufen sollte. Oder nicht?

Das war nur ein Beispiel...
Ich meinte damit, dass man manchmal eben kein getX/setX braucht, weil ein
move(step, direction)
vielleicht besser ist. da man zB die position des objektes nur am anfang setzen muss und es danach nur mehr bewegt.

hängt aber vom kontext ab. weil man uU es trotzdem setzen können muss.

Ich behaupte nicht, dass getter/setter schlecht sind, sondern dass man sie überlegt einsetzen soll. Denn vorallem bei Anfängern sehe ich das oft: jede Membervariable hat einen setter und einen getter - somit haben wir quasi nur public variablen.

Natürlich gibt es auch sehr viele situationen wo man getter/setter braucht - aber man sollte vorher nachdenken, ob der zugriff wirklich so nötig ist.

denn ein move() kann uU besser sein (muss aber nicht)

Oder bei einem auto ein addWheel() statt setWheels()...

[Helium]

Ok, dann habe ich dich falsch verstanden (o; Wobei ich der festen überzeugung bin, dass move() implizit setX und setY aufrufen sollte. Oder nicht?

Ich versteh zwar, was du willst, aber dennochdenke ich, dass das du es etwas falsch angehst. Du baust dir eine kleine, interne Schnittstelle auf, die dann von den anderen Methoden verwendet wird (egal, ob die der eigenen Klasse oder die der Derivate). Somit kannst du die Struktur ändern, ohne dass der Rest der eigenen Klasse oder die Derivate geändet werden müssen.

Du schreibst dir aber pro Variable eine set- und eine get-Methode. Und genau das ist der Kritikpunkt. Brauchst du (auch wenn es nur inern ist) tatsächlich diese Schnittstelle bzw. ist das sinnvoll?

Ein move_to im letzten Beispiel statt eines set_x und set_y ist vermutlich wesentlich sinnvoller. Du kannst darüber immernoch alle anderen Methoden implementieren, kannst diese Methode aber gleich öffentlich machen, da sie Teil der öffentlichen Schnittstelle sein soll. So hast du zwei Fleigen mit einer Klappe geschlagen und als gratis dazu noch ein wesentlich höheres Abstraktionslevel.