Java Quiz

NullPointerException?

Hinzufügen weiß ich jetzt nicht, aber er wollte die Klassen weglassen. Ich sag jetzt aber nicht warum, da könnt ihr euch selbst die Köpfe zerbrechen :stuck_out_tongue: Ich sag nur: Er hat damit recht! Aber die erfahrenen Programmierer machen das ja eh nicht so, von daher halb so wild.

Soweit ich weiß, waren Closures und Generics schon ganz am Anfang geplant, wurden aber wegen Zeitdrucks weggelassen.

[QUOTE=Akeshihiro]Hinzufügen weiß ich jetzt nicht, aber er wollte die Klassen weglassen. Ich sag jetzt aber nicht warum, da könnt ihr euch selbst die Köpfe zerbrechen :stuck_out_tongue: Ich sag nur: Er hat damit recht! Aber die erfahrenen Programmierer machen das ja eh nicht so, von daher halb so wild.[/QUOTE]Wie denn sonst? In einer OO-Sprache sind Klassen doch das A und O (wortwitz). Kann mir nicht vorstellen, ein Java-Programm ohne Klassen zu schreiben. Magst du vielleicht nen Hinweis geben!?

Ok, ich poste es dann doch mal.

During the memorable Q&A session, someone asked him: „If you could do Java over again, what would you change?“ „I’d leave out classes,“ he replied. After the laughter died down, he explained that the real problem wasn’t classes per se, but rather implementation inheritance (the extends relationship).

Also er meint damit nicht die Klassen an sich, sondern die Fähigkeit zu erben bzw. zu vererben, so wie es im Moment der Fall ist. Das Problem ist nämlich, dass die Vererbung oft nicht als Mittel zur Spezialisierung genutzt wird, sondern zur Vereinfachung/Wiederverwendung von „Eigenschaften“ einer Klasse für eine neue Klasse, die aber eben keine spezielle Form davon ist, sondern die geerbte Klasse eigentlich nur „benutzt“. Wir haben hier also ein Beziehungsproblem, daher gibts es ja auch so oft das zu lesen: „Favor Composition over Inheritance“. Und eben genau das wird sehr oft falsch gemacht, selbst in der Java-API selbst ist genau das anzutreffen.

Nein, nein und nochmal nein! Objektorientierung **kann **man über Klassen realisieren, muss man aber nicht. Eine alternative Lösung sind prototypenbasierte Sprachen wie Javascript, Lua, Self und Io. Und Sprachen wie BETA und gbeta vereinheitlichen Klassen und Funktionen zu „Patterns“ bzw „main blocks“.

[QUOTE=Landei]Eine alternative Lösung sind prototypenbasierte Sprachen wie Javascript, … [/QUOTE]Ja, okay. Ich gebe dir recht, das Objektorientierung nicht zwingend Klassen benötigt. Aber jeder der mal mit javascript versucht hat OO zu bauen, wird sie nicht missen wollen. :wink:

Nur weil ein Konzept in einer bestimmten Sprache doof umgesetzt ist, spricht das noch lange nicht gegen das Konzept. Ich bin z.B. ein Fan eines statischen Typsystems, auch wenn Java’s Version davon stark verbesserungswürdig ist (insbesondere in Richtung Typinferenz, aber auch in Bezug auf einige „Löcher“ wie Arrays). Wer aber deswegen zu Ruby oder Python wechselt, schüttet das Kind mit dem Bade aus.

haha genug der diskussion; nächste frage :wink:

Ist zwar nicht kompliziert, aber nicht ausprobieren und versuchen auf zeit im kopf zu lösen: ^^

boolean drehtMeinHirnDurch = 5 > 1 && 8 < 3 || 9 > 1 && 9 < 0 && 2 > 1 || 1 > -4 && (5 * 0 < 4 || 3 == -2) || 3 > 1 * 2 && (8 > 3 * 2 || 7 < 9) || 3 < 8 * 0;

ergebniss?

true

Gestern ist mir was eingefallen, was ich hier mal fragen könnte :slight_smile:

Gegeben sei folgende Klasse:

  String a;
  String b;

  public Quiz(){
     this(???); // <-- Was muss hier rein?
  }

  public Quiz(Map<String, String> map){
     this.a = map.get("a");
     this.b = map.get("b");
  }
}```

Aufgabe ist es nun, beim Default-Konstruktor "a" mit 1 und "b" mit 2 vorzubelegen, OHNE(!) dass statischer Code zum Einsatz kommt oder das Schlüsselwort "class" verwendet wird.

Du meinst doch nicht etwa dieses grausige, grausige Konstrukt

new HashMap<String, String>() 
{
    {
        put("a", "1");
        put("b", "2");
    }
};

!?

Alternativ eine anonyme Klasse, die ebendiese Werte zurückgibt. Ist etwas verbose, sollte aber funktionieren.

     this( new HashMap<String,String>(){ @Override public String get( final Object key) { return Integer.toString( ((int)(((String)key).charAt( 0)) - 96));}});
  }```

[QUOTE=Marco13]Du meinst doch nicht etwa dieses grausige, grausige Konstrukt

new HashMap<String, String>() 
{
    {
        put("a", "1");
        put("b", "2");
    }
};

!?[/QUOTE]Doch, genau das meinte ich :D. Du bist. :wink:

[QUOTE=cmrudolph;65880]Alternativ eine anonyme Klasse, die ebendiese Werte zurückgibt. Ist etwas verbose, sollte aber funktionieren.[/QUOTE]Code?

Murray’s Lösung wäre der Code :wink:

[QUOTE=Akeshihiro]Murray’s Lösung wäre der Code ;)[/QUOTE]Der war noch nicht da, als ich meine Antwort geschrieben hatte. Edit von alten Posts ist böse … :smiley:
@Murray : Ja, das ist natürlich auch eine Lösung. Auch wenn sie etwas fehleranfälliger (Was wenn ich keine String als key übergebe?) und umständlicher als die von Marco13 ist. :wink:

Sorry, die Korrektur hat dann doch länger gedauert als erwartet.

Ja, das ist natürlich auch eine Lösung. Auch wenn sie etwas fehleranfälliger (Was wenn ich keine String als key übergebe?)

Stimmt, besonders fehlertolerant ist das nicht; Leerstrings wären z.B. böse. Aber bei einer Map<String,String> wirst Du schwerlich etwas anderes als einen String als Key verwenden können - außer null, aber das muss eine Map als Key nicht unbedingt unterstützen.

und umständlicher als die von Marco13 ist. :wink:

Einfach ist langweilig :wink:

Was anderes als Trivialitäten wie "Was muss bei den … stehen, damit hier…

... x = ...
if (x != x) System.out.println("Hallo");

das ‘Hallo’ ausgegeben wird?" fällt mir spontan nicht ein.

Der Code müsste heißen

if (x != x) System.out.println("Hallo");```
Geht natürlich auch mit float.

Begründung: NaN-Werte sind darüber definiert, dass sie ungleich zu sich selbst sind. Wird einem spätestens dann bewusst, wenn man sich mal die Implementierung von `Double.isNaN(double v)` anguckt:```static public boolean isNaN(double v) {
	return (v != v);
    }```