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.
Fehler in dem UML Diagramm!
Im UML Diagramm sind zwei Fehler vorhanden(hab die Bestätigung vom Tutor:
Die Variable nextStatement in ALGOStatement muss vom Typ protected und nicht private sein (die Klasse verrerbt ja an die Unterklassen, sonst hätten diese keinen Zugriff auf die Variable der Oberklasse)
Die Methode setValue() in ALGOFloatVariableExpression ist nicht abstrakt, obwohl sie im Diagramm kursiv geschrieben wurde. Ist ja auch logisch es gibt ja keine Unterklasse mehr.
So dann mal viel Spass beim erstellen der Klassen :moody:
So richtig lustig wird aber erst Aufgabenblatt 4, ich sag nur 112 Punkte! :vogel:
Toby
Kann es sein dass da noch ein Tippfehler drin ist?
execute() von ALGOStatement ist als abstrakt definiert. Würde auch Sinn machen, nur dann muss ja ALGOStatement auch abstrakt sein. Ist es aber laut UML-Diagramm nicht… zumindest ist es nicht kursiv.
supi “musterloesung” thumb up
Ja bei mir sind die beiden Oberklassen abstrakt, da der Compiler sonst einen Fehler bringt! Ich denk mal das sind auch Fehler!
Ach ja die Variable value in ALGOFloatVariableExpression darf dann natürlich auch nicht protected sondern muss private sein.
mal ganz ehrlich… wunderts einen denn überhaupt noch? also mich nicht. :rolleyes:
ALGOStatement
Eigentlich muss nextStatement gar nicht unbedingt protected sein.
Weil man ja vielleicht gar ncht will, dass die Unterklassen drauf zugreifen können. Man mus ja nicht alles vererben wollen.
Hab gesehen, dass ein anderes Diagramm im Web hängt mit ein paar fehlern weniger …
die neue vwersion is angeblich auch fehlerfrei…
ich würde mal sagen fast ,)
evaluate kann nur abstract sein, wenn auch ALGOExpression abstract ist. ansonsten müsst sich der rest in dieser form zumindest schonmal compilen lassen… 
laut bernd ludwig is das kein fehler…
wir können nur jetzt noch nicht sehen warums sinnvoll is
was heisst kein fehler? es compiled einfach nicht → unbrauchbar?!
ALGOExpression.java:21: algo.compiler.ALGOExpression is not abstract and does not override abstract method evaluate() in algo.compiler.ALGOExpression
oder eclipse sagt es noch schöner:
The abstract method evaluate in type ALGOExpression can only be defined by an abstract class
welche neue version?
Nur dass es gerade hier bei einer abstrakten Oberklasse doch eigentlich sinnvoll wäre, nextStatement zu vererben oder?
nicht unbedingt, wenn du getNextStatement ganz allgemein in der abstrakten Klasse schon implementieren kannst für alle Abgeleiteten, dann kannst du nextStatement ruhig private lassen solang du die Methode vererbst, die den Job erledigt.
Hmm… man kann ja sogar den Konstruktor, der nextStatement setzt mit super() so basteln, dass alle Unterklassen nextStatement gar nicht kennen müssen… Ist ein Argument, überzeugt. 
Was ist, wenn man mit dem “falschen” gearbeitet hat und damit fertig ist und es sozusagen nicht wusste??? :vogel:
Können die dann sagen: “Das hättet ihr doch sehen müssen!” :vogel:
Shit, hab den Thread hier uebersehen und mich ewig mit dem Zeugs
rumgequaelt :/, habs sogar schon abgegeben nach der Musterloesung. Wenn die mir was abziehen, weil ich die falsche ‘Musterloesung’ richtig umgesetzt habe gibts Zoff 