Testfragen aus dem Buch

[DrippleTripple]

Hi,

erlerne gerade das Programmieren mit Java. Kann mir jemand vielleicht bei den Testfragen helfen. Also ich habe fast alle beantwortet, würde eben gerne wissen, ob ich das richtig gemacht habe, oder ob bei mir noch Wissenslücken vorhanden sind.

Es handelt sich um wahr oder falsch Fragen:

1. Die Deklaration int i = 5.0 erzeugt eine Fehlermeldung. (wahr)
2. Ein Interface kann von höchstens einer Klasse implementiert werden. (falsch)
3. Eine Klassenmethode wird durch den Modifikator static definiert. (wahr)
4. Jede Klasse muss eine Methode mit dem Namen main enthalten. (falsch)
5. Abstrakte Klassen können nicht instanziiert werden. (wahr)
6. Ein Konstruktor ist eine Methode zum Erzeugen von Objekten. (wahr)
7. Konstruktoren werden vererbt. (falsch)
8.Der Typ einer Variablen kann ein Interface sein. (wahr)
9. Alle Methoden einer Klasse müssen unterschiedliche Namen haben. (falsch)
10 Für Exceptions der Klasse RuntimeException gilt die
catch-or-throw-Regel nicht. (wahr)
11.Beim Start eines Java-Programms wird zuerst das null-Objekt erzeugt. (wahr)
12. Eine Klasse darf höchstens eine statische Methode enthalten. (falsch)
13. Wenn einer Methode ein Feld als Parameter übergeben wird,
arbeitet die Methode mit einer Kopie des Felds. (weiß ich nicht…)
14. Der Default-Konstruktor besitzt keine Parameter. (wahr)
15. Schnittstellen lassen sich nicht instanziieren. (wahr)
16. In Java können Ausdrücke Seiteneffekte ausüben. (wahr)
17. Klassenmethoden dürfen den this-Zeiger nicht verwenden. (falsch)
18. Eine Methode kann höchstens einen Vararg-Parameter besitzen. (wahr)
19. Ein statischer Konstruktor wird höchstens einmal
in einem Programmlauf aufgerufen. (falsch)
20. Konstruktoren können verkettet werden. (wahr)
21. Eine Methode kann stets auf alle Instanzvariablen ihrer Klasse
ohne Punktnotation zugreifen. (falsch)
22. this ist eine Variable, die auf das aktuelle Objekt zeigt. (this ist ja ein zeige und keine variable???)
23. In der Anweisung return e muss der Ausdruck e vom Rückgabetyp der zugehörigen Methode sein. (wahr)
24. Ein Konstruktor ist eine Methode ohne Rückgabewert. (wahr)
25. Ein Konstruktor ist eine Methode mit dem Namen der zugehörigen Klasse. (wahr)
26. In jeder Klasse kann höchstens eine Klassenvariable deklariert werden. (falsch)
27. Zwei abgeleitete Klassen können die gleiche Basisklasse besitzen. (wahr)
28. Es gibt Variable, die während ihrer Lebensdauer
auf Objekte verschiedener Typen zeigen können. (weiß ich nicht??? Beispiel?)
29. Eine Klasse, die eine private-Methode enthält, kann abgeleitet werden. (falsch)
30. Eine abstrakte Klasse kann abgeleitet werden. (falsch)

Bitte um kurze Erklärung, wenn ich irgendwo Fehler geamcht habe. Danke!

 

[GilbertGrape]

Gibts zu den Testfragen keine Auflösung?

 

[Schandro]

17.: "wahr", da mann this nicht in einem statischen Kontex benutzen kann
13.: "falsch", Arrays werden als referenz weitergegeben

heißt bei 29 und 30 "ableiten" vererben? Wenn ja sind beide "wahr"

28: Kommt drauf an wie mans definiert. Eine Object-Variable kann z.b. auf alles zeigen. Um den richtigen Typ zu benutzen, müsste es aber wieder gecastet werden.

21. "wahr", Gegenbeispiele?


Alle angaben wie immer ohne Gewähr

 

[DrippleTripple]

Ja doch wenn man sich das Buch mit den Antworten kauft.

Danke für die rückmeldungen!

 

[Spacerat]

19 und 22 würd' ich noch zu "wahr" berichtigen.
19: Was könnte denn ein statischer Konstuktor sein wenn nicht "static {}"? Und der wird nur einmal beim Laden der Klasse aufgerufen.
22: Java und Zeiger (ausser Primitive sind alle Variablen Zeiger für den einen und Referenzen für den anderen... bitte nicht schon wieder so 'ne Disskussion) ... "this" ist also die "Variable" (Konstante triffts eigentlich besser) für das aktuelle Objekt.
zu 13: ... nicht nur Arrays werden als Referenzen übergeben. (ausser Primitive sind alle...)

 

[tfa]

19: Was könnte denn ein statischer Konstuktor sein wenn nicht "static {}"? Und der wird nur einmal beim Laden der Klasse aufgerufen.

Einmal pro Classloader.

 

[fjord]

13. könntest du auch einfach ausprobieren. Ein Feld erzeugen, einer Methode übergeben. In der Methode verändern und nach der Methode testen ob sich was geändert hat am Feld.
@Schandro: zu 21.: Instanzvariablen können durch lokale Variablen verdeckt werden.
23. Bin mir nicht sicher, ob ich die Frage richtig verstanden habe, aber ich würde nein sagen. Ich kann z.B. bei einer Funktion mit Rückgabewert Number auch einen Integer returnen.

 

[Schandro]

23. Bin mir nicht sicher, ob ich die Frage richtig verstanden habe, aber ich würde nein sagen. Ich kann z.B. bei einer Funktion mit Rückgabewert Number auch einen Integer returnen.

Seh ich auch so.
Zu 21: nicht dran gedacht. 21. ist "falsch"

 

[Spacerat]

@tfa: >Einmal pro ClassLoader... autsch... Verschiedene ClassLoader -> Verschiedene Klassen! zwar hat man durchaus die Möglichkeit eine existierende Klasse noch mal mit dem selben Inhalt zu laden, aber das macht wohl keinen Sinn. ClassLoader sind auch nicht wirklich was für "Anfänger".
@fjord: zu 23: das geht durchaus. Und wenn man jetzt noch mit "das selbe ist nicht das gleiche" kommt, müsste man hier auch "falsch" sagen.

 

[Marco13]

Zu 13: Die Antwort is "wahr". In Java gibt es nur Call-By-Value. (<-Punkt).

 

[Schandro]

Wenn mit Feld Array gemeint ist:

13 ist "falsch"!
Es arbeitet nicht mit einer Kopie des Feldes. Ansonsten würde es bedeuten das das Array geclont wird. Wenn da "eine Kopie der Referenz" stehen würde, wäre es "wahr"

€: (warum sollte mit "Feld" "Referenz" gemeint sein?)

 

[Noctarius]

Wenn mit Feld Array gemeint ist:

13 ist "falsch"!
Es arbeitet nicht mit einer Kopie des Feldes. Ansonsten würde es bedeuten das das Array geclont wird. Wenn da "eine Kopie der Referenz" stehen würde, wäre es "wahr"

€: (warum sollte mit "Feld" "Referenz" gemeint sein?)

Wahr, weil die Objektreferenz auf das Array eine Andere ist. Call-By-Value heißt nicht, dass das gesammte Objekt gecloned wird sondern nur die Referenz auf selbiges. Der Speicherbereich dahinter ist der selbe.

[highlight=java]public class Test {
}

public class Foo {
public static void main(String[] args) {
Object[] array = new Object[] { new Test(), new Test(), new Test() };

System.out.println(array);

callWithParameter(array);
}

public static callWithParameter(Object[] array) {
System.out.println(array);
}
}[/highlight]

Der zweite Aufruf müsste laut JLS eine andere Objekt-Referenz-Id werfen



edit - Restlichen Antworten meiner Meinung nach:

17. Klassenmethoden dürfen den this-Zeiger nicht verwenden.
wahr: In Klassenmethoden gibt es keine Instanz als auch kein this

19. Ein statischer Konstruktor wird höchstens einmal in einem Programmlauf aufgerufen.
wahr: Stimmt, da erstens kaum ein Anfänger mit Classloadern arbeitet und zweitens ein anderer CL eine andere Klasse (zu mindestens für die VM) erzeugt

21. Eine Methode kann stets auf alle Instanzvariablen ihrer Klasse ohne Punktnotation zugreifen.
wahr: [highlight=java]public class Foo {
private Object object = null;

public Object getObject() { return object; }
}[/highlight]

22. this ist eine Variable, die auf das aktuelle Objekt zeigt.
wahr: Prinzipiell ist this die aktuelle Instanz also ein Objekt und damit eine Variablen-Referenz

24. Ein Konstruktor ist eine Methode ohne Rückgabewert.
falsch: Der Konstruktor hat einen nicht definierbaren Rückgabewert. Die Instanz der Klasse.

28. Es gibt Variable, die während ihrer Lebensdauer auf Objekte verschiedener Typen zeigen können.
wahr?: Auf Superclasses oder implementierende Interfaces
[highlight=java]Integer test = 1;
Number test2 = test;[/highlight]

30. Eine abstrakte Klasse kann abgeleitet werden.
wahr: denn es gilt "5. Abstrakte Klassen können nicht instanziert werden. (wahr)"
Was willst du mit denen machen wenn nicht ableiten oder instanzieren?

 

[Schandro]

An Noctarius:

Der zweite Aufruf müsste laut JLS eine andere Objekt-Referenz-Id werfen

Das ist schön. Mein Java gibt 2 mal dasselbe aus.
Compiles mal selber. Ich bin immer noch für 13: "falsch"

Hoffentlich entsteht hier jetzt net noch ne Diskussion, ob die JLS oder die Sun VM richtiger ist, das sind nur 30 dumme Anfängerfragen, die nicht zu wortgenau beantwortet werden wollen.

€dit: Wie schon oben festgestellt, ist die 21 "falsch"!
Bsp:
[highlight=Java]

private int i;

public void foo(){
int i = 0;
// greif mal auf die Membervariable ohne "this." zu...
}
[/highlight]

Nochmal €dit:
omfg was ne beschissene Frage. Die Antwort ist doch "wahr":
[highlight=Java]

private int i;

public void foo(){
int i = 0;
System.out.println(getI());
}

public int getI(){return i;}
[/highlight]

 

[Noctarius]

Ähm werd ich nachher mal machen ^^ Dann wäre ein Array das einzige Objekt, dass wie ein primitiver Typ gehandled wird... mag sein ^^

 

[Schandro]

Nein, ein Array wird deshalb genauso wie jedes andere Object behandelt.

JButton b1 = new JButton();
JButton b2 = b1;

hashCode von b1 == hashCode von b2

Oder meisnt du mit Referenz-ID nicht sowas wie den HashCode? Imho gibts sowas nicht, das man die ID einer Referenz ANSICH rausbekommen kann

 

[Spacerat]

@Schandro & Noctarius: Call-by-Value hat im Prinzip nichts damit zu tun, das trotzdem eine Referenz übergeben wird. Es heisst schlicht, das die Referenz innerhalb der Methode neu zugewiesen werden darf, ohne das der Aufrufer was dafon mitbekommt. Call-by-Reference sieht in C++ z.B. so aus:

void method(IDENTIFIER * something) {}

Hier kann ein Zeiger (zur Not auch eine Referenz) auf eine Variable übergeben werden. Weist man dieser innerhalb der Methode einen anderen Wert zu, bekommts auch der Aufrufer mit.

 

[fjord]

[...]
Nochmal €dit:
omfg was ne beschissene Frage. Die Antwort ist doch "wahr":
[highlight=Java]

private int i;

public void foo(){
int i = 0;
System.out.println(getI());
}

public int getI(){return i;}
[/highlight]

du greifst in foo() nicht auf i sondern eine Kopie von i zu

 

[Noctarius]

Call-By-Value heißt nicht, dass das gesammte Objekt gecloned wird sondern nur die Referenz auf selbiges.

Genau das mein ich doch. Das Objekt wird beim übergeben aber nicht gecloned.

 

[Marco13]

Das "(<-Punkt)" hinter meiner Aussage sollte eigentlich andeuten, dass es dazu keine Diskussion (mehr) geben muss/müssen sollte, aber ich mag solche Grundsatzdiskussionen ja auch manchmal

Wenn man
System.out.println(object)
macht, wird effektiv String.valueOf(object) ausgegeben (schon DAran sieht man, dass es ein Problem wäre, wenn etwas anderes ausgegeben werden würde, nur weil das an String.valueOf weiterdelegiert wird) - schließlich ist das was ausgegeben wird dann sowas wie
object==null?"null"bject.toString()

Und was bei "toString" zurückgegeben wird, ist immer gleich, wenn die Referenz auf das gleiche Objekt verweist. Es werden zwar in Java bei Methodenaufrufen immer nur Referenzen übergeben, aber was in der Methode ankommt, ist eben eine KOPIE dieser Referenz.

Man könnte jetzt in die philosophische Diskussion übergehen, ob mit "ein Feld" denn nun die Referenz gemeint ist, oder das, worauf die Referenz zeigt, oder nur das abstrakte Gedankenkonstrukt was eine Eigenschaft der Objekte dieser Klasse beschreibt, aber da "Field" auf What Is an Object? (The Java™ Tutorials > Learning the Java Language > Object-Oriented Programming Concepts) mit einer Variable gleichgesetzt wird, und abgesehen von primitiven Datentypen alle Variablen in Java Referenzen sind, kann man wohl von ersterem ausgehen.

Und demnach wird das Feld (d.h. die Variable) kopiert.

private int x[] = new int[0];

void doit()
{
    System.out.println(x); // Das hier...
    call(x);
    System.out.println(x); // ... gibt das gleiche aus wie das hier, darum kann ....
}

void call(int a[]) //... hier nur eine Kopie der Referenz angekommen sein
{
    a = new int[0];
}

 

[Marco13]

Call-by-Reference sieht in C++ z.B. so aus:

void method(IDENTIFIER * something) {}

Hier kann zur Not ein Zeiger auf eine Variable übergeben werden. Weist man dieser innerhalb der Methode einen anderen Wert zu, bekommts auch der Aufrufer mit.

Bei call-by-reference in C++ steht dort ein Ampersand ("&") - DAS wiederum hat nichts damit zu tun, ob dort ein Pointer oder irgendwas anderes übergeben wird...

private int x = 123;

void X::doit()
{
    cout << x; // Gibt 123 aus
    call(x);
    cout << x; // Gibt 456 aus
}

void X::call(int &a) // Das hier ist call-by-reference
{
    a = 456;
}

 

[Schandro]

Eigentlich sind wir uns alle (glaub ich) einig. Es ist einfach nicht klar, was ein "Feld" ist.
Ich hab von einem Feld als Array geredet (wie ich oben auch immer wieder geschrieben hab). Warum?
Wikipedia, erster Satz von http://de.wikipedia.org/wiki/Feld_(Datentyp)
"Ein Feld (engl. Array..."

Außerdem ist so eine Frage, die sich auf Arrays bezieht, für anfänger sinvoll, da viele am Anfang denken, ein komplettes Array würde bei ner Übergabe als Parameter kopiert werden...

Wie wärst denn jetzt mit nem
"(<-Punkt)"

 

[Marco13]

Ich bin bei "Feld" davon ausgegangen, dass das ein eingedeutschtes "Field" ist - in dem Sinne ist zwar jeder Array ein Feld, aber nicht umgekehrt wie auch immer. Wer präzise (in diesem Fall: Richtige) Antworten will, muss auch präzise Fragen stellen...

 

[Spacerat]

Bei call-by-reference in C++ steht dort ein Ampersand ("&") - DAS wiederum hat nichts damit zu tun, ob dort ein Pointer oder irgendwas anderes übergeben wird...

Das Ampersand steht dort nur bei der Parameterübergabe, wenn man eine Referenz übergibt...

// Funktuions-Porototyp aus OpenAL
AL_API void AL_APIENTRY alGetIntegerv( ALenum param, ALint* data );

vllt. verwechselst du das mit PHP, wo bei der Definition tatsächlich ein "&" steht.

 

[DrippleTripple]

Meine güte... muss ich jetzt schon alles verstehen???

 

[Noctarius]

Nein ^^ überlies 80% der Posts ^^

Die korrigierten Antworten am Anfang sind schon ok, nur Frage 13 ist komisch formuliert

 

[Spacerat]

Nee... eigentlich gar nicht, wenn du bei Java (ohne JNI) bleibst. Letztendlich: "streiten" wir uns nur ob 13 nun falsch oder wahr ist... Die ist aber auch unglücklich formuliert. Also wenn man von Call-by-Value (das gleich merken) ausgeht, muss sie aber falsch sein...
(edit: bei nochmaligem Überlegen... Hat doch mit Call-by-Value eigentlich gar nichts zu tun... geht doch eigentlich nur darum, das ich, wenn ich innerhalb der Methode Member des übergebenen Objekts ändere diese nach aussen hin auch sichtbar werden. Anders, als wenn ich das Objekt vorher clone.)

 

[DrippleTripple]

alles klar danke!

kann mir jemand noch mit den C1 und C0 tests helfen...

 

[Marco13]

Das Ampersand steht dort nur bei der Parameterübergabe, wenn man eine Referenz übergibt...

// Funktuions-Porototyp aus OpenAL
AL_API void AL_APIENTRY alGetIntegerv( ALenum param, ALint* data );

vllt. verwechselst du das mit PHP, wo bei der Definition tatsächlich ein "&" steht.

Ich bin ja selten so ... insistiv... aber... wenn ich weiß, dass ich recht habe... : Wenn man bei der Übergabe der Parameter (also beim Aufruf der Funktion) (oder vor eine bereits deklarierte Variable) ein "&" schreibt, dann ist das der Adressoperator, der "dafür sorgt, dass IN der Funktion ein Pointer ankommt". Es gibt aber auch Referenzen, die AUCH durch ein & kenntlich gemacht werden, aber NUR bei der Deklaration - und diese Deklaration kann auch in der Parameterliste einer Funktion stehen. Schau auch mal hier Reference (C++) - Wikipedia, the free encyclopedia) - Bei "Uses of references" steht auch ganz anschaulich, was denn "Call By Reference" wirklich bedeutet. (Vielleicht sollte man nochmal betonen: Java-Referenzen und C++-Referenzen haben nichts miteinander zu tun - zwischen Java-Referenzen und C++-Pointern gibt es schon eher Parallelen ... (irgendwo muss ja der Grund dafür liegen, dass es NullPointerException und nicht NullReferenceException heißt ))


EDIT: Link korrigiert

 

[Spacerat]

Ok... das muss ich dann so hinnehmen. Man lernt halt nicht aus.
Der Link funzt im übrigen nicht so ganz... die Letzte Klammer kommt nicht mit...