Get/Set

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

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

@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

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

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