Frage

Gibt es eine verkürzte Möglichkeit, generische Definitionen zu definieren und zu verwenden, ohne eine bestimmte generische Beschreibung ständig wiederholen zu müssen, sodass ich bei einer Änderung nicht alle Definitionen/Verwendungen innerhalb der Codebasis ändern muss? So etwas ist beispielsweise möglich:

Typedef myGenDef = < Object1, Object2 >;

HashMap< myGenDef > hm = new HashMap< myGenDef >();

for (Entry< myGenDef > ent : hm..entrySet())
{
.
.
.
}
War es hilfreich?

Lösung

Da ist das Pseudo-Typedef-Antimuster...

class StringList extends ArrayList<String> { }

Gute Sache, trinkt!;-)

Wie der Artikel feststellt, weist diese Technik einige schwerwiegende Probleme auf, vor allem, dass diese „Typedef“ tatsächlich eine separate Klasse ist und daher weder mit dem Typ, den sie erweitert, noch mit anderen ähnlich definierten Typen austauschbar verwendet werden kann.

Andere Tipps

In einer generischen Methode können Sie eine eingeschränkte Form der Typinferenz verwenden, um einige Wiederholungen zu vermeiden.

Beispiel:wenn du die Funktion hast

    <K, V> Map<K, V> getSomething() {
        //...
    }

Sie können Folgendes verwenden:

final Map<String, Object> something = getsomething();

anstatt:

final Map<String, Object> something = this.<String, Object>getsomething();

Verwenden Fabrikmuster zur Erstellung von Generika:

Methodenbeispiel:

public Map<String, Integer> createGenMap(){
        return new HashMap<String,Integer>();

    }

Das von Shog9 erwähnte Pseudo-Typedef-Antipattern würde funktionieren – obwohl die Verwendung eines ANTIPATTERN nicht empfohlen wird –, aber es entspricht nicht Ihren Absichten.Das Ziel von Pseudo-Typedef besteht darin, die Unordnung in der Deklaration zu reduzieren und die Lesbarkeit zu verbessern.

Sie möchten in der Lage sein, eine Gruppe von Generika-Deklarationen durch einen einzigen Handel zu ersetzen.Ich denke, man muss innehalten und nachdenken:„Inwiefern ist es wertvoll?“Ich meine, ich kann mir kein Szenario vorstellen, in dem Sie das brauchen würden.Stellen Sie sich Klasse A vor:

class A {
     private Map<String, Integer> values = new HashMap<String, Integer>();
}

Stellen Sie sich jetzt vor, ich möchte das Feld „Werte“ in eine Karte ändern.Warum sollten viele andere Felder im Code verstreut sein, die die gleiche Änderung erfordern?Für die Operationen, die „Werte“ verwenden, würde ein einfaches Refactoring ausreichen.

NEIN.Groovy, eine JVM-Sprache, ist jedoch dynamisch typisiert und ermöglicht das Schreiben von:

def map = new HashMap<complicated generic expression>();
Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top