Get/Set

[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.

[bozo]

@junix

es ging um diese ausage von dir:

junix schrieb:

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

junix schrieb:

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.

da gibt es keinen widerspruch

junix schrieb:

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.

bloss das du eben mit deiner uraussage dich nicht auf der sicheren seite befindest und auch nicht die konsequenzen verstehst die sich daraus ergeben,
da du sie einfach nicht genau formuliert hast, und wenn ich weitere aussagen von dir lese, siehe die nächste, dann hast du es auch nicht verstanden und meinst es auch wirklich falsch,

junix schrieb:

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.

siehe deine ursprüngliche aussage, wenn ein attribut nur klassenintern verwendet wird, warum zur hölle soll es dafür public zugriffsmethoden geben können? damit bist du überhaupt nicht mehr auf der sicheren seite, du gestattest jemand zugriff auf ein attribut das ihn überhaupt nichts angeht

junix schrieb:

Du bist allerdings nicht minder fundamentalistisch, wenn du dich auf Struppi stützt in deiner Argumentation... Auch Struppi hat nicht überall recht.

LOL
warum soll man nicht auch was der entwickler von c++ zu sagen hat mit in seine überlegungen einbeziehen?
dies ist ja gerade dein problem,
du bist total in deiner ansicht festgefahren und kannst nichts anderes mehr erkennen und verstehen, jedenfalls wird dies anhand deiner ausführungen offensichtlich

junix schrieb:

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...

darum codet man aber nicht unsichere und sinnlose funktionalität in eine klasse, siehe oben und die bisherige diskussion,
auch sollte man sich bei der erstellung der klasse an die zu diesem zeitpunkt geforderte funktionalität halten und keine nicht gebrauchte zusätzliche funktionalität einbauen, die garnicht gefordert ist und sicher auch nie benutzt wird, da man ja die zukunft nicht vorhersehen kann,
wenn später etwas gebraucht wird erledigt man diese aufgabe zu diesem zeitpunkt, dann weis man auch was man wirklich benötigt und muss sich nicht auf vorhersagen der zukunf verlassen

junix schrieb:

Aber weisst du was? Was laber ich hier eigentlich... du hast recht. Ich lieg komplett falsch.
So, nu hat die diskussion ein Ende.

du verstehst es nicht, es geht mir nicht darum wer hier recht hat, was wohl bisher deine motivation war, sondern ich wollte hinweisen, dass deine uraussage (und jetzt inzw. leider auch einige deiner späteren aussagen), so nicht allgem.zutreffen,
es ist echt schade, dass du, wohl schon seit deiner ersten antwort, einfach auf eine konfrontation aus warst,
der rest ist ja echt nur kindliches gefassel

junix schrieb:

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.

und nun nochmal, vielleicht klappt es ja diesmal,
deine uraussage/lösung ist einfach teileweise
falsch - public zugriffsmethoden, zugriff von abgeleiteter klasse und
sinnlos - private daten, private zugriffsmethoden; sind bei der überwältigenden zahl der anwendungsfälle unnötig, und wenn es irgendwelche beschränkungen gibt sind spez. methoden besser als allgem. get/set methoden, die nichts genaues aussagen
nur unterbestimmten umständen (z.b. threadsicherheit), die man sehr wohl festlegen und auch ausschliessen kann, kann deine lösung sinnvoll sein,
aber auch nur wenn sie richtig gemacht wird und genau auf diese umstände zugeschnitten und nicht deine wahllose verwendung ohne sinn und verstand

du verallgem. von einem spezialfall einfach auf eine generelle lösung, welche immer benutzt werden sollte und proklamierst es dann so,
aber dem ist eben nicht so,
darum wollte ich auf die damit verbundenen probleme hinweisen,
aber irgendwie musst du dich da persönlich angeriffen gefühlt haben,
naja, dein problem,
andere haben es besser verstanden

[junix]

Helium schrieb:

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.

Exakt. Ich sehe dir ist klar, dass der Ausdruck "Zugriffsmethoden" nicht automatisch "public" impliziert.

Helium schrieb:

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?

Naja ich drücks mal etwas anders aus: ich konzentriere die Variablenzugriffe auf eine Funktion um die kontrolle über Zugriffe und damit auch über Seiteneffekte jederzeit haben zu können.

Helium schrieb:

Ein move_to im letzten Beispiel statt eines set_x und set_y ist vermutlich wesentlich sinnvoller.

Nur bedingt. Im Falle des Spielers wäre wohl move_to eine Verkettung mehrerer Schritte welche ausgeführt werden oder nicht? Also mehrerer set_x und set_y? (zum Beispiel)

-junix

[Helium]

Nur bedingt. Im Falle des Spielers wäre wohl move_to eine Verkettung mehrerer Schritte welche ausgeführt werden oder nicht? Also mehrerer set_x und set_y? (zum Beispiel)

Ich würde sagen genau ein Aufruf von set_x und einer von set_y.

Aber ein move_to wäre auch wenn du auf ein polar-Koordinatensystem umstellst kein Problem, wogegen ein set_x und set_y jedes mal Umrechnungen zur folge hätten, obwohl es so aussieht, als wäre es etwas ganz primitives.

[bozo]

junix schrieb:

Naja ich drücks mal etwas anders aus: ich konzentriere die Variablenzugriffe auf eine Funktion um die kontrolle über Zugriffe und damit auch über Seiteneffekte jederzeit haben zu können.

wenn man es in dieser art machen will, gibt es aber auch eine unsicherheit

(ich sage mal nichts dazu, ob ich diese art für sinnvoll halte, muss wohl jeder für sich selbst entscheiden)

als beispiel benutze ich den fall private daten und private zugriffsfunktionen

und ich gehe, von deinen bisherigen post's, davon aus, dass du etwas in der art des folgenden benutzt, also eine datenvariable und zugehörige get und set methoden:

class Something
{
...
private:
	int data;
	void setData(int in) { data = in; }
	int getData() { return data; }
...
};

das problem ist, dass nur deine einstellung, zugriff auf daten nur mit den get/set funktionen, und deren befolgung bei der programmierung dich davon ab hält, die daten auch direkt, ohne die zugriffsmethoden, in einer anderen methode zu benutzen,
du hast keine unterstützung durch die sprachsyntax, die dies verhindert

als vergleich dazu: im private daten und public zugriffsmethoden fall, verhindert die sprachsyntax die direkte benutzung der daten

müsstest du dann nicht eher eine andere sichere variante benutzen um wirklich die sicherheit und kontrolle zu haben?

z.b. als schnell entstandene idee zur anregung das folgende:

#include <iostream>
#include <string>

template<class T> class Data
{
private:
	T data;
public:
	void set(const T& in) { data = in; }
	const T& get() const { return data; }
};

class SampleClass
{
public:
	void DoSomething()
	{
		data2.set(4);
		data1.set(data2.get() * 2);
		std::cout << "data1 = " << data1.get() << std::endl;
		std::cout << "data2 = " << data2.get() << std::endl;
		text.set("Testtext.");
		std::cout << "text = " << text.get() << std::endl;
	}	

private:
	Data<int> data1;
	Data<int> data2;
	Data<std::string> text;
};

int main(void)
{
	SampleClass sample;

	sample.DoSomething();

	return 0;
}

[Helium]

@bozo:

Wo liegt da der Sinn? Ich denke es geht auch um Dinge, wie Design By Contract.

'Data' ist hingegen nur eine unnötige Verkomplizierung (toller Neologisnmus ).

Wenn du es nischt schaffst irgendwie noch die "Verträge" an dein 'Data' zu übergeben, ist es sinnlos.

[bozo]

@Helium

Wo liegt da der Sinn?

das frage ich mich auch, aber schon bei der art von j....

(sorry, konnte nicht widerstehen, es noch mehr in die sinnlosigkeit zu treiben)

[junix]

@Helium: stimmt... was bonzo da vorschlägt ist absolut sinnlos. Es braucht keine Data klasse. DAS ist wirklich am Ziel vorbei. Wozu für ein Attribut und 2 Methoden eine ganze Klasse bilden?

-junix

[bozo]

LOL

@Helium: stimmt... was junix da vorschlägt ist absolut sinnlos. Es braucht keine Zugriffsmethoden. DAS ist wirklich am Ziel vorbei. Wozu für ALLE! Attribute SINNLOSE und UNNÖTIGE Zugriffsmethoden bilden?