Warum static Gespenster gespenstErzeugen()

[kostonstyle]

Hallo
meine frage, warum verwendet man um statische Methode zu erzeugen static Gespenster gespenstErzeugen(), würde static gespenstErzeugen() nicht genügen?

class Gespenster {
   static int anzahl = 0;
   String name;

   private Gespenster() {
      ++anzahl;
      name = "Gespenst" + anzahl;
   }

   static Gespenster gespenstErzeugen() {
      if (anzahl < 3)
         return new Gespenster();
      else
         return null;
   }

   void spuken()  {
      System.out.println("\t" + name + ": Huuhuu!");
   }

}

public class StatischeMethoden {
    
   public static void main(String[] args) {
      System.out.println();

      Gespenster gespenst1 = Gespenster.gespenstErzeugen();
      Gespenster gespenst2 = Gespenster.gespenstErzeugen();
      Gespenster gespenst3 = Gespenster.gespenstErzeugen();
      Gespenster gespenst4 = Gespenster.gespenstErzeugen();
      Gespenster gespenst5 = Gespenster.gespenstErzeugen();

      System.out.println(" Es spuken zurzeit "
                          + Gespenster.anzahl + " Gespenster.");

      if (gespenst1 != null) gespenst1.spuken();
      if (gespenst2 != null) gespenst2.spuken();
      if (gespenst3 != null) gespenst3.spuken();
      if (gespenst4 != null) gespenst4.spuken();
      if (gespenst5 != null) gespenst5.spuken();

      System.out.println();
   }
}

danke kostonstyle

 

[Landei]

Nein, würde es nicht. Eine Methode (statisch oder nicht) braucht immer einen Rückgabewert. Nur bei Konstruktoren kann (und muss) man den weglassen. Woher soll der Compiler sonst wissen, was gespenstErzeugen zurückliefert? Nur weil die Methode so heißt? Du kannst genausogut schreiben:

 static Zombie gespenstErzeugen() {
    return new Zombie();
 }

Natürlich könnte ein intelligenterer Compiler in einer intelligenteren Sprache sowas rausknobeln, in dem er in die Methode hineinschaut (das nennt sich Typinferenz), aber leider tut er das nicht in Java. Java ist strunzdoof, du musst ja sogar schreiben

Gespenst gespenst = new Gespenst();

obwohl es hier für den Compiler ziemlich einfach wäre, selber drauf zu kommen, welchen Typ die Variable hat.

 

[diggaa1984]

Jede Methode verlangt nen Rückgabewert, der in dem Falle Gespenter entspricht.
Das is keine Zauberei

 

[kostonstyle]

aha, dann ich dasselbe wenn ich das schreiben würde

static int gespenstErzeugen()

Warum nimmt man hier der Klassename als Rückgabewert? Klassenname kann doch nicht entscheiden, ob es ganzzahlig oder kommazahlen sind.......

 

[SirGecco]

Hier wird ein Objekt vom Typ Gespenster zurückgegeben. (also nicht ein String, int, etc.)

 

[diggaa1984]

man gibt ja immer das zurück wofür die methode gedacht ist, erzeugeGespenst soll dir also ein Objekt der Klasse erzeugen und gibt dir die Referenz darauf zurück.

Is wie beim Getränkeautomaten .. da steckst geld rein, drückst aufn knopp und weil man am Getränkeautomat Getränke kaufen kann, bekommst auch selbiges, und nicht nur das Bild was aufm Knopf ist

 

[0x7F800000]

intelligenterer Compiler

bwoah ey, ohne end' hier werbung für scala machn^^
Wieso bezeichnest du das als "intelligenter" ? Ich dachte eigentlich immer, dass diese ganzen typangaben eher für menschen gedacht waren. Dass es ohne typen geht, sieht man ja auch in javascript (wobei das bei scripts freilich was anderes ist), aber allzu kompliziert ist sowas nicht. Ist halt einfach eine entscheidung der designer: manche mögen's lieber wenn der benutzer sich die ganze zeit im klaren ist, was für typen er da verwendet, andere dagegen haben auch so alles bestens unter kontrolle, und lassen das lieber vom "intelligenteren" compiler erledigen

 

[Ark]

Map x = new HashMap(100);

@Landei: Woher soll der Compiler ohne explizite Angabe wissen, dass du dich bei x auf Map beschränken (um Flexibilität zu behalten) und du dich auf der rechten Seite für HashMap mit genau diesem Konstruktor festlegen willst? Welche der Informationen in dieser Zeile ist redundant?

Ark

 

[Landei]

Ich dachte eigentlich immer, dass diese ganzen typangaben eher für menschen gedacht waren.

Nein, der Compiler nutzt Typen vorn und hinten, um zu prüfen, dass du keinen Quatsch machst. Deshalb kannst du z.B. überladene Methoden schreiben:

   void spuke(Gespenst gespenst) {...  }
   void spuke(Geist geist) {...  }
   void spuke(HalloweenKid kid) {...  }

und der Compiler sucht den richtigen Aufruf heraus.

Die Abneigung vieler Leute gegen statische Typprüfung ist verständlich (wenn man sich anschaut, was uns Java zumutet), aber unbegründet (wenn man sich anschaut, was gute Typsysteme leisten können), und ich denke, dass man beim Wechsel zu dynamisch getypten Sprachen (JS, Ruby, Groovy, Python) vom Regen in die Traufe kommt: Man spart sich (vermeintlich) etwas Tipparbeit, dafür poppen die Fehler nicht beim Compilieren, sondern nach der Auslieferung beim Kunden hoch :-D
Wenn man kompliziertere Sachen mit Typen macht, hilft einem der Compiler sogar, Denkfehler zu vermeiden.


@Ark: Darauf gibt es zwei Antworten:
1) Man kann natürlich Typen angeben, wenn man z.B. eine Oberklasse haben will, also auf "scalanisch"

val x:Map[String] = new HashMap[String]

2) In der Praxis kommt es aber darauf gar nicht so sehr an, d.h. es stört nicht, dass x eine HashMap anstatt Map ist, weil du dich in Scala so selten auf den Typ beziehen musst. x ist zwar HashMap, aber du brauchst trotzdem nur eine Stelle (nämlich die Definition), um daraus eine TreeMap zu machen. Das kommt natürlich einerseits durch die TypInferenz, andererseits davon, dass Scala finale Variablen (vals) bevorzugt, so dass sich das Problem, dass du vielleicht irgendwann mal x eine TreeMap zuweisen willst, gar nicht stellt.

 

[Ark]

x ist zwar HashMap, aber du brauchst trotzdem nur eine Stelle (nämlich die Definition), um daraus eine TreeMap zu machen.

Mal abgesehen davon, dass x zumindest in meinem Beispiel nur vom Typ Map ist, sehe ich in dem Zitierten keinen wirklichen Unterschied zu Java. Habe ich das Entscheidende daran wohl übersehen? ???:L

Ark

 

[Landei]

Höchstens, dass es in Java "wahrscheinlicher" als in Scala ist, dass man x eine andere Map zuweisen will, und dann Pech hat, wenn x eine HashMap statt einer Map ist. Ansonsten kein großer Unterschied...

 

[0x7F800000]

   void spuke(Gespenst gespenst) {...  }
   void spuke(Geist geist) {...  }
   void spuke(HalloweenKid kid) {...  }

und in Scala ist selbst das unnötig, weil's einem ins hirn schauen kann oder wie? ???:L irgendwie kann ich nicht so recht glauben, dass man in Scala auch sowas weglassen darf. Soweit geht das mit der typinferenz dann auch nicht.

Und was wollt ihr alle mit dieser schreibarbeit? Was'n das für ein argument?
Es gibt zweifellos sprachen die zur unnötigen schreibarbeit zwingen, wo man einfachste sachen auf unübersichtliche kilometerlange codebrocken verstreuen muss, und wo der sinn verlorengeht.

Aber ob ich "x" oder "int x" hinschreibe... da wird der code wohl kaum unübersichtlicher, eher im gegenteil.

 

[Ark]

[...] und dann Pech hat, wenn x eine HashMap statt einer Map ist.

Ähh, nein?! Das ist wohl falsch. Was du da schreibst, heißt für mich, x könnte eine HashMap sein, ohne zugleich auch eine Map zu sein; also x ist HashMap, aber nicht Map. Aber das ist falsch. Jede HashMap ist auch eine Map. Und ob bzw. wo da Scala jetzt Wunder was für Informationen nicht braucht, ist mir nach wie vor ein Rätsel.

Aber nenn uns doch bitte mal einen typischen Fall, in dem Scala echte Vorteile gegenüber Java vorzuweisen hat.

Ark

 

[0x7F800000]

Aber nenn uns doch bitte mal einen typischen Fall, in dem Scala echte Vorteile gegenüber Java vorzuweisen hat.

*zumindest was Typinferenz betrifft
Irgendwelche Vorteile wird's schon haben, einfach weil's nicht von den ganzen ansprüchen von allen Seiten belastet, und dadurch irgendwie "gelähmt" wird.

 

[Landei]

und in Scala ist selbst das unnötig, weil's einem ins hirn schauen kann oder wie?

Typinferenz heißt ja nicht, dass man alle Typen weglassen kann, sondern nur die, die der Compiler sicher ableiten kann.

Methodenparameter gehen schonmal prinzipiell nicht. Dagegen kann bei Funktionen meistens der Rückgabe-Typ aus dem Rückgabe-Wert gefolgert werden, z.B. hätte folgende Funktion den Rückgabewert Double:

def wurzel(x:Int) = Math.sqrt(x)

@Ark: Ich glaube, wir reden aneinander vorbei. Was ich meine ist: Wenn du (egal ob in Java oder Scala, oder mit Typinferenz oder ohne) schreibst:

HashMap<String>x = new HashMap<String>()

dann schränkst du damit deine Flexibilität ein, weil du der Variablen jetzt keine Objekte anderer Map-Typen zuweisen kannst. Das heißt, in diesem Fall wäre Typinferenz von Nachteil, und man tut besser daran, x als Map zu definieren. Da Scala allerdings viel mehr finale Variablen ("val") verwendet, ist das nicht so schlimm, genauso wie in Java

final HashMap<String>x = new HashMap<String>()

kein Problem ist, da man x ja sowieso kein anderes Objekt mehr zuweisen kann. Hoffe, das war einigermaßen verständlich - ist schwer zu erklären, wenn man es nicht mal selbst probiert hat.

Aber nenn uns doch bitte mal einen typischen Fall, in dem Scala echte Vorteile gegenüber Java vorzuweisen hat.

Ich hänge mich mal soweit aus dem Fenster zu sagen: Immer!
Und zwar wegen:
- Typinferenz
- Pattern Matching, Case Classes
- Mixin-Komposition ("Interfaces auf Steroiden")
- Closures, Funktionen als Objekte "erster Klasse"
- Aktoren zur parallelen Programmierung (ähnlich wie in Erlang)
- funktionaler Programmier-Stil möglich (immutable Objekte, Currying)
- implizite Argumente und implizite Typ-Konvertierung
- kein static - saubere Trennung von Objekt- und Klassencode duch Einführen von Begleiter-Objekten
- Programmieren ohne Verwendung null viel einfacher
- direkte XML-Unterstützung
- mächtigeres Typsystem
- läuft notfalls auch auf .NET
- kann auch als Script oder in einer interaktiven Shell laufen
- Lazy Evaluation von Variablen möglich
- Operator-Überladung
- kürzere Syntax mit weniger Ausnahmen
...aber da hab ich sicher einiges vergessen

 

[0x7F800000]

ist schwer zu erklären, wenn man es nicht mal selbst probiert hat.

iss gut, ich glaub's

 

[Guest]

Wenn du (egal ob in Java oder Scala, oder mit Typinferenz oder ohne) schreibst:

HashMap<String>x = new HashMap<String>()

dann schränkst du damit deine Flexibilität ein, weil du der Variablen jetzt keine Objekte anderer Map-Typen zuweisen kannst.

Sag mal, rede ich chinesisch? Wenn ich das schreibe, was du denkst, hast du vielleicht Recht, aber das interessiert mich nicht, weil ich nämlich schreibe:

Map x = new HashMap(100);

Und ich stelle dir jetzt dieselbe Frage noch einmal: Welche der Informationen in dieser Zeile ist redundant?

Zu deiner Liste: Von den Punkten, die du nennst, sagen mir einige gar nichts, aber zu einigen kann ich was sagen (meine Meinung!):
1. Von der Idee, dass Typen automatisch erkannt werden, halte ich als als jemand, der Compiler als Absicherung sieht, nichts. Bei den Typen geht es ja vor allem um Zuweisungen, und Zuweisungen haben immer eine linke Seite und eine rechte Seite. Als Java-Programmierer lege ich, wenn man so will, sowohl den Typ der linken als auch den der rechten Seite fest, und der Compiler gibt mir grünes Licht, wenn auf der linken Seite der Zuweisung tatsächlich der gleiche Typ steht wie auf der rechten Seite. Das ist wie doppelte Buchführung: eine derartige Redundanz erhöht die Sicherheit bzw. verringert die Fehlerquote.
2. Ich programmiere auch in Sprachen, die kein Äquivalent zu null haben, und der Code ist deswegen immer nur umständlicher geworden.
3. Von eigenmächtiger Operatorüberladung halte ich persönlich ebenfalls nichts. Die ausführliche Begründung habe ich vor langer Zeit mal irgendwo in der Plauderecke (glaube ich) gegeben.
4. Die Sache mit XML finde ich lobenswert. Allerdings muss ich dazusagen, dass ich mich diesbezüglich in Sachen Java noch gar nicht wirklich beschäftigt habe. Insofern ist diese (meine) Einschätzung qualitativ nicht sehr hochwertig.

Wie du hoffentlich siehst, muss man nicht alles, was du nanntest, für gut befinden.

Ark

 

[Ark]

Das gerade war übrigens ich ...

Warum habe ich in diesem Forum immer unglaubliche Schwierigkeiten, mich angemeldet zu halten, obwohl ich alles mir Bekannte dazu unternehme? ???:L

Ark