Ergebnis 1 bis 11 von 11

Thema: Vector<class> laden und speichern per Java

Hybrid-Darstellung

Vorheriger Beitrag Vorheriger Beitrag   Nächster Beitrag Nächster Beitrag
  1. #1
    Zitat Zitat von YoshiGreen Beitrag anzeigen
    Ist die Wildcard <?> für den Vector wirklich nötig? Bei mir kompiliert es auch ohne diese Angabe - oder ist das Platform/Versionsabhängig?
    Theoretisch sollte es egal sein, da Vector ein Raw-Type ist und <?> einen unbekannten Typ definiert. Da alle Datentypen von der Klasse Object erben, sollten beide Möglichkeiten gleich sein. Allerdings spuckt z.B. die IDE Eclipse einen Warnhinweis, wenn man mit einem Raw-Type arbeiten möchte.


    Zitat Zitat von YoshiGreen Beitrag anzeigen
    Und gibt es einen Grund die Klassen auf String-Ebene zu vergleichen? Im folgenden Beispiel habe ich die equal-Methode der Class-Klasse genutzt. (und wenn der fragliche Vector als Paramter übergeben wird, spart man sich doch auch die if != null Abfrage),
    Man muss hier zweierlei Dinge betrachten. Einmal der Typ Vector und einmal der Typ, der im Vektor gespeichert wird.
    Du kannst ja gerne mal einen Test machen:
    Code:
    public static boolean hasStrings(Vector data){
        System.out.println((new Vector<String>().getClass()));
        System.out.println(data.getClass());
        return new Vector<String>().getClass().equals(data.getClass());
      }
    Du wirst feststellen, dass beide vom Typ Vector sind. Es spielt da keine Rolle, welcher generische Datentyp angegeben wurde. In der Klasse Vector befindet sich ja eine Liste, die den angegebenen generischen Typ speichert. Man muss dann also schauen, welchen Typ die Elemente in dieser Liste besitzen.

  2. #2
    OK, das hatte ich übersehen und nun auch eingesehen. Meine Frage richtete sich aber auf die toString()-Methode da equal() ja auch für Klassen definiert ist.
    Code:
    return vector.get(0).getClass().toString().equals(new String().getClass().toString());
    Kannst du mir dazu noch sagen wonach ich googlen soll wenn ich folgenden Code zum laufen bringen will:
    Code:
    Class cl = new String().getClass();
    Vector<cl> vec = new Vector<cl>();
    Can't find symbol ist mein Fehler aber es wäre praktisch eine Methode zum Überprüfen zu haben anstelle sie zu überlagern.

  3. #3
    Zitat Zitat von YoshiGreen Beitrag anzeigen
    OK, das hatte ich übersehen und nun auch eingesehen. Meine Frage richtete sich aber auf die toString()-Methode da equal() ja auch für Klassen definiert ist.
    Stimmt. Da hatte ich einen Gedankenfehler.

    Zitat Zitat von YoshiGreen Beitrag anzeigen
    Kannst du mir dazu noch sagen wonach ich googlen soll wenn ich folgenden Code zum laufen bringen will:
    Code:
    Class cl = new String().getClass();
    Vector<cl> vec = new Vector<cl>();
    Can't find symbol ist mein Fehler aber es wäre praktisch eine Methode zum Überprüfen zu haben anstelle sie zu überlagern.
    cl ist kein Datentyp, sondern eine Variable vom Typ Class.
    Das, was du da vorhast könnte man bei Sprachen mit schwacher Typisierung machen, die alles als Zahlen oder Zeichenketten (z.B. TorqueScript in der Torque Game Engine) behandeln, aber nicht bei einer Sprache mit starker Typisierung.
    Aber warum hast du sowas vor? Du willst doch letzendlich nur Strings in den Vektor speichern.

  4. #4
    Zitat Zitat von YoshiGreen Beitrag anzeigen
    Code:
    Class cl = new String().getClass();
    Vector<cl> vec = new Vector<cl>();
    Can't find symbol ist mein Fehler aber es wäre praktisch eine Methode zum Überprüfen zu haben anstelle sie zu überlagern.
    Also du willst auf einen variablen generischen Typ casten?
    Das macht inhärent keinen Sinn, da die Type Constraint bei generischen Klassen bloß statisch überprüft wird, bei der Programmausführung ist darüber keinerlei Information mehr vorhanden. Dynamisch einen generischen Parameter zu bestimmen ergibt daher keinen Sinn, da der im dynamischen Kontext eben nicht mehr vorhanden ist und auch nicht mehr verwendet/überprüft wird.

    Wenn der Typ erst zur Laufzeit feststeht, kannst du einfach Vector (oder Vector<Object>) verwenden, genau das wird da zur Laufzeit nämlich in jedem Fall stehen.

  5. #5
    Naja, meine Idee war einfach nur Konstruktionen wie diese hier zu vermeiden:

    Code:
      private static boolean sameClass(Vector data, Vector v){
        return new Vector().getClass().equals(data.get(0).getClass());
      }
    
      private static boolean sameClass(Vector data, String s){
        return new String().getClass().equals(data.get(0).getClass());
      }
    Und stattdessen halt sowas wie
    Code:
    public static boolean sameClass(Vector data, Class cl){
      return data.get(0).getClass().equals(cl);
    }
    oder etwas ähnliches. Die obere Lösung halte ich für so unelegant. Aber vielleicht habe ich ja auch einen total falschen Ansatz. Habe halt noch nie vorher Objekte gespeichert.

  6. #6
    Zitat Zitat von YoshiGreen Beitrag anzeigen
    Code:
    public static boolean sameClass(Vector data, Class cl){
      return data.get(0).getClass().equals(cl);
    }
    Hm, das sollte doch eigentlich eh gehen, oder? o_O Bräuchte evtl. höchstens noch etwas Code um Unterklassen zu berücksichtigen. Und du könntest ein Objekt statt der Klasse als zweiten Parameter übergeben, je nachdem, was praktischer ist.
    Oh, und du solltest auf jeden Fall sichergehen, dass data nicht leer ist, sonst gibt's unschöne Runtime Exceptions …

    Ahja, in jedem Fall kannst du im Falle von Class auch == statt equals() verwenden, da Class-Objekte Singletons sind. Aber geht natürlich so genauso.

  7. #7
    Code:
    private static boolean sameObject(Vector<?> v, Object obj) 
    {
        return !v.isEmpty()
               ? v.get(0).getClass().equals(obj.getClass())
               : false;
    }

  8. #8
    Ich kam noch net zum testen. Beim Übergeben von ner Class hatte ich irgendwelche Probleme (ich versuchs bezeiten nochmal zu rekonstruieren, Whiz Code teste ich dann auch).

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •