Disclaimer: Dieser Thread wurde aus dem alten Forum importiert. Daher werden eventuell nicht alle Formatierungen richtig angezeigt. Der ursprüngliche Thread beginnt im zweiten Post dieses Threads.
Aufgabe 6.4
Hey ne Frage…
In der Aufgabenstellung steht:
Ich hoffe mal stark, das dies nicht für die jeweilige Klasse selbst gilt…
Die Setter und Getter Methoden sind eigentlich nur für andere Klassen (nicht für Klasse selbst) gedacht
Wäre außerdem ein Widerspruch: Ich greife von einem anderen Objekt und dem Objekt selbst über diese Methoden auf die Instanzvariablen zu
Der Widerspruch wäre: Wie greifen dann die Methoden (des Objekts) selbst auf diese Instanzvariablen zu? auch über sich selbst? (->Rekursive Endlosschleife^^)
Also ich hoffe, dass diese Einschränkung nicht für die klasse selbst gilt… weil sonst wären die Aufgaben ja nicht lösbar (siehe Widerspruch)
Abgesehen von dem Widerspruch:
Zudem würde ein Konstruktur der die Variablen erst an die Setter-Methoden weiterleitet sehr exotisch aussehen
Und ich darf dann hoffentlich auch in bspw. attack() direkt auf die Objektvariablen von dem Objekt in dem attack definiert ist zugreifen!
Lg knotenpunkt
PS: Alle die schon mal was von OOP gehört haben können sich die 32GP in weniger als einer halben Stunde verdienen^^
Im Normalfall dürfte damit der Zugriff von anderen Klassen aus gemeint.
Zumindest hab ich noch nie von Punktabzug gehört, wenn man intern nicht ausschließlich die Getter- und Setter-Methoden benutzt. 
Allerdings würde ich behaupten, dass das Benutzen von Getter/Setter-Methoden innerhalb der eigenen Klasse schon in bestimmten Fällen sinnvoll sein kann.
Beispielsweise könnte man private Set-Methoden dazu verwenden, Instanz-Variablen nach außen hin als schreibgeschützt zu präsentieren, intern möchte man aber beispielsweise die Veränderungen der Variable mitzählen (oder ähnliches). Auch das Debuggen wird dadurch erleichtert, wenn man nur an der Stelle, wenn die Variable verändert wird, anhalten möchte.
Auch kommt es ein bisschen auf die Programmiersprache an. In C# beispielsweise gibt es ja die Möglichkeit der Benutzung von Eigenschaften (als eine Art Notationsform).
Eine Eigenschaft (Property) ist dabei nichts anderes, als eine mit Getter und Setter gekapselte Instanz-Variable, wobei man allerdings nur eine Eigenschaft deklariert, anstatt eine Variable und zwei Methoden hinschreiben zu müssen. Da es nur diese Eigenschaft gibt, benutzt man auch innerhalb der Klasse automatisch immer die implizit vorhandenen Getter und Setter.
Möchte man nun nicht, dass die Eigenschaft nach außen hin änderbar ist, wird einfach der Set-Accessor als private deklariert.
Weil ich jetzt sehr stark auf die Setter und deren Möglichkeiten eingegangen bin: Meine persönliche Meinung dazu ist, dass in Settern grundsätzlich mehr als nur das reine Setzen der Variable erlaubt sein sollte.
Neben Logging gibt es ja noch diverse Anwendungsmöglichkeiten. Allerdings finde ich es nicht so toll, wenn in Gettern noch sehr viel gemacht wird, bevor der eigentliche Wert zurückgegeben wird.
Der einzige Fall, bei dem ich persönlich Getter um mehr Funktionen erweitere, ist Lazy Initialization (beispielsweise bei einem Modell, das erst dann die Werte aus einer Datenbank ausliest, wenn das erste Mal der Getter aufgerufen wird).
Ich denke es ist klar, dass ein Getter oder Setter nicht sich selbst verwenden sollte.
Aber ich finde nicht, dass die Verwendung von Gettern und Settern in der Klasse selbst auf jeden Fall als schlecht bezeichnet werden kann.
Wie immer ist natürlich davon abraten, verschiedene Praktiken zu mischen.
Ist auch alles ein bisschen Ansichtssache. Ich lass mich da gerne von Besserem überzeugen.
1 Like
Hey ceptoplex,
habe des mit den getter und setter auf die aufgabe bezogen und wollte nur mal den Widerspruch aufzeigen, der dabei entsteht wenn man die Aufgabenstellung von dene Wortwörtlich nimmt^^
Aber noch was anderes: In den Testfällen/Angaben von denen ist noch ein Fehler:
Man muss >1 verwenden damit der Testfall funktioniert
Und das Besiegen ist auch nicht richtig definiert… wann wird ein Avatar besiegt (nach Testfall wohl auch >1)
Achja noch ein Tipp: Man kann nur einmal besiegt werden^^ (also wenn lifepoints schon/noch bei 1 bzw. 0 sind dann kann/sollte man kein zweites mal besiegt werden können)
->entsprechender Testfall gibt es nicht… ist eventuell auch bewusst weggelassen worden (für geheime testfälle)
Komsicher weiße muss aber gelten dass man mehrmals unter 0 bzw. 1 mit den Lifepoints kommen kann (dass Testfall passt)
Aufgabenstellung sagt aber
Also einmal
Ich finde dass die Aufgabenstellung(en) dieses mal wirklich richtig verbugt ist/sind
Seit wann?
Angenommen ich will mit jeder Änderung der Instanzvariable oder jedem Zugriff darauf eine Debug/Log-Nachricht irgendwohin schreiben.
Ich werde das sicher nicht an 1000 Stellen im Code einzeln einbauen, sondern ich bau das in die Getter und Setter Methoden.
Oder ich will in der Setter Methode den übergebenen Wert prüfen…
In beiden Fällen verwende ich auch in der jeweiligen Klasse die Getter und Setter Methoden.
Den Widerspruch verstehe ich nicht. :huh:
In der Aufgabenstellung ist doch explizit erlaubt, dass die Getter und Setter Methoden direkt auf die Instanzvariablen zugreifen dürfen.
Also spätestens in der Getter und Setter Methode hört die Funktionsaufrufkette auf.
Endlosrekursionen durch wechselseitige Aufrufe, kommen in der Aufgabenstellung nicht vor. 
Doch sind sie.
Wieso? Auch hier willst du eventuell Log/Debug-Ausgaben haben, die Werte prüfen, etc.
Nein! 
Jep. 
Also alle, die gestern in der Vorlesung waren?
1 Like
[quote=knotenpunkt]
Man muss >1 verwenden damit der Testfall funktioniert [/quote]
Ist in der Aufgabenstellung inzwischen korrigiert.
„Unter 0 fallen“ ist hier eine ungünstige Formulierung. Man soll auch experience erhalten wenn der Gegner schon negative lifePoints hat (siehe Testfall).
Mal abgesehen davon, dass 90% des Beitrags von pug gschmarri ist… (ich zerlege den Beitrag in einem späteren Kommentar noch^^)
Ist der Instanzvariablenzugriff von der Klasse selbst mittels getter/setter ein Kriterium für den EST-Main/geheimen Test
Wann ist man gestorben, wann genau gibts levelup, wann genau werden die Waffen ausgetauscht…
Stimmen die Est-Tests mit den vorgegeben Tests überein
Bei mir siehts noch nicht korrigiert aus
Mal ganz ehrlich schreibt mal eine vernünftige und vor allem EINDEUTIGE und mit den Tests übereinstimmende Aufgabenstellung von vornherein und nicht immer im Verlaufe der Woche
9 Likes
Hm, ich habe hier alle Test-Ergebnisse richtig, aber das EST zeigt mir ein Ausrufezeichen an.
Ich hatte vermutet, dass es sich um die fehlenden Getter/Setter Aufrufe handelt (es hatten tatsaechlich ein paar gefehlt), aber ich habe mittlerweile alle eliminiert, und es zeigt mir immer noch Gelb an.
Irgendjemand eine Idee?
Ich freu mich ja schon auf den Post…
Rein interessehalber hätte ich ja gerne mal gewusst, wie man Methoden wie [m]attack()[/m] auf Objekten definiert. Das muss neu in Java 7.knotenpunkt sein oder ich hab das Memo dazu einfach verpasst…
1 Like
Ok tut mir Leid, reicht wahrscheinlich jetzt. :o)
3 Likes
Watt is denn nu? Wir warten gespannt…
Verstehe ich richtig, dass man für z.B. innere Methode addLifePoints(int) die Methoden getLifePoints() bzw. setLifePoints benutzen sollte statt direktes Zugriff auf Instanzvariable? Danke.
Genau richtig verstanden!
Mein Thread ist derzeit noch blockiert syncronized{wait();}
Ihr habt euren rekursiven Basisfall nicht richtig gesetzt
if
(
)
{return;}
Mein Thread wacht (notify() aber erst wieder auf wenn ihr euren Basisfall richtig gesetzt habt
sprich ihr solltet auch noch folgende Punkte abarbeiten:
Wieso sollten sie? Oft genug haben Setter/Getter auch ein bisschen Logik zB. Umrechnung in eine andere Einheit, abprüfen von gewissen Eigenschaftern, asserts, call von Listenern, logging, Zugriff auf private Variabeln der Super-Klasse, lazy-loading etc. und da du diesen Code nicht wiederholen möchtest schreibst du ihn in die Getter und Setter.
Im Normalfall würde man das nicht machen, aber für die oberen Beispiele ergibt sich das einfach.
Das ist kein valides Argument. Man kann im Debugger durchaus einen Breakpoint auf Instanzvariabeln setzen, welcher bei Access und/oder Modification stoppt. Damit erkennst du auch Zugriffe die über foo.x passiert sind.
[quote=Absurd-Mind][quote=ceptoplex:1385080616]
Auch das Debuggen wird dadurch erleichtert, wenn man nur an der Stelle, wenn die Variable verändert wird, anhalten möchte.
[/quote]
Das ist kein valides Argument. Man kann im Debugger durchaus einen Breakpoint auf Instanzvariabeln setzen, welcher bei Access und/oder Modification stoppt. Damit erkennst du auch Zugriffe die über foo.x passiert sind.
[/quote]
Das war lediglich als positiv auftretender Seiteneffekt gemeint.
Ist aber korrekt, was du sagst.
Ja
Man ist tot, wenn die lifePoints <= 0 sind.
levelUp gibt es, wenn nach einer Attacke die lifePoints des Gegners <= 0 sind.
Die Waffen werden ausgetauscht, wenn nach einer Attacke die lifePoints des Gegners <= 0 sind und die Waffe des Gegners sowohl mehr Schaden anrichtet als die eigene, als auch weniger abgenutzt ist.
Ja
Mit eine der Hauptaufgaben von Settern ist die Validierung der Parameter damit das Objekt möglichst immer in einem sinnvollen Zustand bleibt. Würde man im Konstruktor nicht die Setter benutzen würde das nur zu doppeltem Code führen.
1 Like