3. Get/Set

Get/Set

  • J

    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

    0
  • ?

    @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

    0
  • J

    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

    0
  • J

    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

    0
  • ?

    @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

    0
  • ?

    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

    0
  • J

    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

    0
  • J

    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

    0
  • ?

    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

    0
  • S

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

    0
  • J

    @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

    0
  • J

    -überzählig-

    0
  • J

    -zuviel-

    0
  • 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
Anmelden zum Antworten