3. Get/Set

Get/Set

  • S

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

    0
  • H

    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.

    0
  • ?

    @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 🙂

    0
  • J

    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

    0
  • H

    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.

    0
  • ?

    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;
}
    0
  • H

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

    0
  • ?

    @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)

    0
  • J

    @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

    0
  • ?

    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?

    0
Anmelden zum Antworten