ich schreibe demnächst meine Klausur in Programmieren 2 und ich mache mich nun an die
Multiple-Choice-Fragen ran. Ich habe hier einfach mal die aufgeschrieben, bei denen
ich mir unsicher bin, oder bei denen ich keine Ahnung habe. Es wäre wirklich nett von euch,
Wenn ihr euch das mal kurz antun könntet
01 Der int-Wert eines Objekts der Wrapper-Klasse Integer
kann durch Methoden verändert werden.
02 Widgets dürfen nur in Applets benutzt werden.
03 Mit den Methoden wait und notify kann das Recht, sich in einem
kritischen Bereich zu befinden, zwischen Threads wechseln.
04 Wrapper-Klassen sind unveränderlich (immutable).
05 Wrapper-Klassen sind final.
06 Für jede .java-Datei erzeugt der Compiler genau eine
.class-Datei.
07 Eine Klasse kann zu mehreren Paketen gehören.
08 Serialisierung ist eine Möglichkeit, Persistenz von
Daten zu erreichen.
09 Enum-Klassen können instanziiert werden.
10 Die Klasse String ist final.
11 Werte einer Enum-Klasse können nicht verändert werden.
12 Ein Konstruktor darf nicht den Modifikator private besitzen
13 Von anonymen Klassen lassen sich keine Objekte erzeugen
14 Von lokalen Klassen lassen sich keine Objekte erzeugen.
15 Serialisierung ist eine Möglichkeit, Persistenz von Daten
zu erreichen.
16 Typebounds schränken die möglichen Parameter generischer
Klassen ein.
17 Die Methoden wait und notify können nur Threads ausführen,
die sich in einem Monitor befinden.
Hier meine Gedanken zu einigen der Fragen:
Zu 01: Wrapper-Klassen sind ja Immutable (unveränderlich), daher ist das doch falsch?
Zu 05: Wrapper-Klassen sind Immutable, also sind sie doch auch final, oder etwa nicht?.
Zu 07: Mehrere Pakete können Klassen mit den gleichen Namen haben, aber die Klasse Peter
dem Paket Uschi kann doch nicht auch gleichzeitig im Paket Klaus sein, stimmts?
Zu 10: Die Klasse String ist ja keine Wrapper-Klasse und ist daher nicht Immutable, oder Final, oder was meint ihr?
Zu 11: Enum-Klassen in Java sind, wenn ich mich recht entsinne, Immutable. Bin mir nicht ganz sicher
Lag ich mit meinen Gedankengängen zumindest einigermaßen richtig? Wer kennt die Antworten für,
die anderen Fragen, oder kann mir einen kleinen Schubser in die richtige Richtung geben?
Ich wäre euch für eure Hilfe wirklich sehr Dankbar
Viele Grüße
NikeAir22
Edit:
Oha…Das da oben ist ja ein ziemliches Durcheinander…ich lade mal lieber kurz ein Bild hoch, bei dem ich das auch schön sauber bei Notepad++ aufgeschrieben habe
[QUOTE=NikeAir22]
Hier meine Gedanken zu einigen der Fragen: Zu 05: Wrapper-Klassen sind Immutable, also sind sie doch auch final, oder etwa nicht?.[/QUOTE]Die Wrapper-Klassen sind Immutable, weil alle ihre Properties (also ihr Wert) final und damit unveränderlich sind.
Ob die Klasse selbst final deklariert ist hat damit nichts zu tun.
Die Wrapper-Klassen sind allesamt final, das ist richtig. Das hat aber nichts damit zu tun, ob die Objekte auch immutable sind. Nur weil eine Klasse nicht mehr erweitert werden kann, heißt das nicht, dass die Instanzen selbst auch unveränderlich sein müssen. Es kommt einfach drauf an, wie die Klasse implementiert wurde und welche Schnittstelle für die Außenwelt bereitstellt. Das sind zwei verschiedene Paar Schuhe.
Bei den Wrapper-Klassen ist eh klar, dass da in jeglicher Hinsicht nichts geht. Aber eigentlich müsste man doch schon auf die Wortwahl achten. Die Fragen 4 und 5 sind genau genommen dasselbe. Was fehlt ist eben, ob die Objekte bzw. die Instanzen einer solchen Wrapper-Klasse auch immutable sind.
Das heißt wir haben jetzt folgendes:
Eine Klasse, die final ist, ist auf Klassenebene immutable. Das schließt aber nicht automatisch die Instanzen ein, die können deswegen trotzdem mutable sein. Das gilt auch umgekehrt. Bei den Wrapper-Klassen der primitiven Datentypen sind auch die Instanzen selbst immutable.
Vielleicht/Wahrscheinlich war mit Frage 4 genau der letzte Punkt gemeint, aber sicher sein kann man sich da nicht, da der Wortlaut dafür genau genommen falsch ist. Also da muss man aufpassen. Habe selbst, als ich mein Fachabi gemacht habe, vom Berufskolleg mit ein paar aus meiner Klasse an einer FH an Programmiersprachen 1 und 2 teilgenommen, natürlich mit voller Punktzahl absolviert. Musste sogar auf einen Fehler aufmerksam machen, den der Professor übersehen hatte. Klingt jetzt natürlich geil und als wärs nix, aber man muss dennoch aufpassen. Manchmal kann ein einziges Wort darüber entscheiden, was eigentlich gemeint ist und dann wird es knifflig, denn folgt man nun dem genauen Wortlaut oder der vermeindlichen Bedeutung … Ich selbst folge in solchen Situationen dem genauen Wortlaut. Auch wenn was anderes gemeint war, so steht es schwarz auf weiß und wenn es nach Wortlaut richtig ist, dann hat es als richtig gewertet zu werden, egal was gemeint war.
In einer Java-Datei dürfen auch mehrere Top-Level-Klassen stehen, nur dürfen die zusätzlichen (die nicht so heißen wie die Datei) nicht public sein. Beim Compilieren bekommen auch diese zusätzlichen Klassen eigene class-Dateien.
Ich erweiter das mal noch um die Tatsache, dass Top-Level-Klassen gar keinen Modifier haben dürfen, also packge-private sein müssen. Bei private und protected knallts ebenfalls.
Ansonsten wird für jede Klasse in einer Datei eine eigene class-Datei erzeugt, also für jede Top-Level-Klasse, für jede innere Klasse und für jede anonyme Klasse.
Wrapper brauchen immer ne neue Instanz
wait & notify bei Nebenläufigkeit
in einer .java-Datei können mehrere Klassen und so sein
ein Klasse → ein Paket
Stichwort: Serialisierung & Enum & Singleton
Jetzt muss ich mal schauen, was die anderen so haben.
Okay, zunächst mal vielen Dank. Bei welchen Fragen bist du dir denn unsicher? Wenn es wirklich um die Enum Frage geht (09), dann bin ich mir sicher, dass man Enum-Klassen nicht instanziieren kann, und deine Antwort somit richtig war.
Das Ding ist aber, das intern mit Instanzen von Variablen/Attributen der Enum-Klasse hantiert wird.
Aber für mich ist das zwar neumodisch und leserlicher, aber ich verwende das so gut wie nie.
Meist verwende ich psf int’s oder Switch-Case über Strings von Konsoleneingaben oder Übergabeparametern. Vielleicht kann @Landei einmal prüfen, ob meine Angaben in etwa richtig sind (also richtig/richtig, falsch/richtig, richtig/falsch usw.)
#02 ist “falsch”. “Widget” bezeichnet jedes GUI-Element, mit dem der Nutzer interagieren kann (so steht z.B. SWT für “Standard Widget Toolkit”, und das hat nichts mit Applets zu tun).
#09 ist dumm formuliert. Ich darf keine Enum-Objekte instanziieren, aber die JVM schon. Aber wahrscheinlich wird hier “falsch” als Antwort erwartet
#15 ist missverständlich. Durch die Serialisierung kann man Persistenz erreichen (wenn der entsprechende Stream irgendwo gespeichert wird), aber das passiert nicht “automatisch”. Man kann natürlich mit Serialisierung auch andere Sachen anstellen, etwa kommunizieren. Trotzdem wird hier wohl die Antwort “richtig” erwartet.
[QUOTE=Landei]#02 ist „falsch“. „Widget“ bezeichnet jedes GUI-Element, mit dem der Nutzer interagieren kann (so steht z.B. SWT für „Standard Widget Toolkit“, und das hat nichts mit Applets zu tun).
#09 ist dumm formuliert. Ich darf keine Enum-Objekte instanziieren, aber die JVM schon. Aber wahrscheinlich wird hier „falsch“ als Antwort erwartet
#15 ist missverständlich. Durch die Serialisierung kann man Persistenz erreichen (wenn der entsprechende Stream irgendwo gespeichert wird), aber das passiert nicht „automatisch“. Man kann natürlich mit Serialisierung auch andere Sachen anstellen, etwa kommunizieren. Trotzdem wird hier wohl die Antwort „richtig“ erwartet.[/QUOTE]
Okay, vielen Dank. Dann habe ich noch eine kleine Frage. Und zwar habe ich noch eine letzte Frage gefunden, bei der ich noch etwas unsicher war:
„Es können gleichzeitig mehrere Klassen als Typebound auftreten.“
Da in Java nur immer von einer Klasse geerbt werden darf, währe es ziemlich sinnlos in einem Typbound verlangen zu können, von mehreren Klassen abgeleitet zu sein, daher: Falsch (Korrigiere mich wer, wenn ich irre).
Aber: In einem Typbound kann eine Klasse und mehrere Interfaces auftreten, wobei die Klasse immer zuerst genannt sein muss. Sieht dann so aus: GenericClass<G extends SomeClass & Interface1 & Interface2>Sollte imo in der Praxis aber eher vermieden werden, da es doch sehr unübersichtlich werden kann.
