Wie auf ein generischer Rückgabetyp mit mehreren Begrenzungen

Während der Typ-Parameter von generischen Methode kann eingeschränkt werden, indem Grenzen, wie extends Foo & Bar sind Sie letztendlich entscheiden die Anrufer. Wenn Sie anrufen getFooBar(), der Aufruf der Seite schon weiß, was T wird aufgelöst. Oft, diese Art von Parametern wird abgeleitet durch den compiler, weshalb Sie nicht in der Regel müssen Sie angeben, wie diese:

FooBar.<FooAndBar>getFooBar();

Aber selbst wenn T abgeleitet werden FooAndBar, das ist wirklich, was passiert hinter den kulissen.

Also, um Ihre Frage zu beantworten, wie eine syntax wie diese:

Foo&Bar bothFooAndBar = FooBar.getFooBar();

Würde nie in der Praxis. Der Grund dafür ist, dass der Anrufer muss schon wissen was T ist. Entweder T ist einige konkrete Typ:

FooAndBar bothFooAndBar = FooBar.<FooAndBar>getFooBar(); //T is FooAndBar

Oder T ist eine ungelöste parameter "type" und wir sind in seinem Geltungsbereich:

<U extends Foo & Bar> void someGenericMethod() {
    U bothFooAndBar = FooBar.<U>getFooBar(); //T is U
}

Anderes Beispiel:

class SomeGenericClass<V extends Foo & Bar> {
    void someMethod() {
        V bothFooAndBar = FooBar.<V>getFooBar(); //T is V
    }
}

Technisch, das hüllt die Antwort. Aber ich möchte auch darauf hinweisen, dass dein Beispiel-Methode getFooBar ist inhärent unsicher. Denken Sie daran, dass der Anrufer entscheidet, was T bekommt, nicht die Methode. Da getFooBar nimmt keine Parameter in Bezug auf T, und weil der type erasure, Ihre einzigen Optionen sind, wäre die Rückkehr null oder zu "Lügen", indem Sie eine unchecked cast, riskieren heap pollution. Ein typischer workaround wäre für getFooBar zu nehmen Class<T> argument, oder sonst eine FooFactory<T> zum Beispiel.

Update

Es stellt sich heraus, ich war falsch, wenn ich behauptete, dass der Anrufer von getFooBar muss immer wissen, was T ist. Wie @MiserableVariable Punkte heraus, gibt es einige Situationen, in denen das typargument einer generischen Methode abgeleitet, um eine wildcard capture, statt einen konkreten Typ oder Typ-variable. Sehen seine Antwort für ein großartiges Beispiel für eine getFooBar Umsetzung, dass ein proxy verwendet wird, nach Hause zu fahren sein Punkt, dass T ist unbekannt.

Wie wir diskutiert in den Kommentaren, ein Beispiel mit getFooBar erzeugt Verwirrung, da braucht es keine Argumente, um zu folgern T aus. Bestimmte Compiler wirft einen Fehler auf einem zusammenhangslosen Aufruf getFooBar() während andere sind gut mit dabei. Ich dachte, dass die inkonsistente Fehler bei der Kompilierung zusammen mit der Tatsache, dass der Aufruf FooBar.<?>getFooBar() illegal ist - bestätigt meinen Punkt, aber dieser entpuppte sich als Ablenkungsmanöver.

Basierend auf @MiserableVariable Antwort, ich habe ein neues Beispiel verwendet eine generische Methode mit einem argument zu entfernen, die Verwirrung. Angenommen, wir haben Schnittstellen Foo und Bar und eine Implementierung FooBarImpl:

interface Foo { }
interface Bar { }
static class FooBarImpl implements Foo, Bar { }

Wir haben auch eine einfache container-Klasse, umschließt eine Instanz eines Typs Umsetzung Foo und Bar. Es erklärt eine dumme statische Methode unwrap nimmt FooBarContainer und gibt Ihr referent:

static class FooBarContainer<T extends Foo & Bar> {

    private final T fooBar;

    public FooBarContainer(T fooBar) {
        this.fooBar = fooBar;
    }

    public T get() {
        return fooBar;
    }

    static <T extends Foo & Bar> T unwrap(FooBarContainer<T> fooBarContainer) {
        return fooBarContainer.get();
    }
}

Nun sagen wir, wir haben ein wildcard-parametrisierten Typ von FooBarContainer:

FooBarContainer<?> unknownFooBarContainer = ...;

Dürfen wir passieren unknownFooBarContainer in unwrap. Dies zeigt meiner früheren Behauptung war falsch, denn der call-site nicht weiß, was T ist - nur, dass es einige geben innerhalb der Grenzen extends Foo & Bar.

FooBarContainer.unwrap(unknownFooBarContainer); //T is a wildcard capture, ?

Als ich merkte, ruft unwrap mit einer wildcard-ist auch illegal:

FooBarContainer.<?>unwrap(unknownFooBarContainer); //compiler error

Ich kann nur vermuten, dass dies ist, weil wildcard erfasst, kann nie mit jeder anderen - die ? argument an der call-site ist mehrdeutig, mit keine Möglichkeit zu sagen, dass sollte es insbesondere entsprechen die Platzhalter in der Art von unknownFooBarContainer.

So, hier ist der use case für die syntax der OP ist gefragt. Aufruf unwrap auf unknownFooBarContainer liefert eine Referenz vom Typ ? extends Foo & Bar. Wir können ordnen, dass der Verweis auf Foo oder Bar, aber nicht beides:

Foo foo = FooBarContainer.unwrap(unknownFooBarContainer);
Bar bar = FooBarContainer.unwrap(unknownFooBarContainer);

Wenn aus irgendeinem Grund unwrap waren teuer und wir wollten nur rufen Sie es einmal, wir wären gezwungen, Darsteller:

Foo foo = FooBarContainer.unwrap(unknownFooBarContainer);
Bar bar = (Bar)foo;

So ist dies, wo die hypothetische syntax würde in handliches kommen:

Foo&Bar fooBar = FooBarContainer.unwrap(unknownFooBarContainer);

Dies ist nur eines ziemlich obskuren use-case. Es wäre ziemlich weitreichende Konsequenzen für die eine solche syntax, sowohl gute als auch schlechte. Es eröffnet sich Raum für Missbrauch, wo Sie nicht benötigt, und es ist völlig verständlich, warum die Sprache-Designer nicht umsetzen ist so eine Sache. Aber ich denke immer noch, es ist interessant zu denken.

Ein Hinweis zur heap pollution

(Meist für @MiserableVariable) Hier eine Exemplarische Vorgehensweise, wie eine unsichere Methode, wie getFooBar verursacht heap-Luftverschmutzung, und deren Auswirkungen. Die folgende Schnittstelle und Implementierungen:

interface Foo { }

static class Foo1 implements Foo {
    public void foo1Method() { }
}

static class Foo2 implements Foo { }

Let ' s implementieren eine unsichere Methode getFoo ähnlich getFooBar aber vereinfacht für dieses Beispiel:

@SuppressWarnings("unchecked")
static <T extends Foo> T getFoo() {
    //unchecked cast - ClassCastException is not thrown here if T is wrong
    return (T)new Foo2();
}

public static void main(String[] args) {
    Foo1 foo1 = getFoo(); //ClassCastException is thrown here
}

Hier, wenn der neue Foo2 geworfen zu T, es ist "nicht aktiviert", was bedeutet, da der type erasure die Laufzeit der es nicht kennt, sollte scheitern, obwohl es in diesem Fall, da T war Foo1. Anstelle der heap ist "verunreinigt", was bedeutet, Referenzen auf Objekte, die Sie sollten nicht erlaubt gewesen.

Den Ausfall geschieht nach der Methode zurückgegeben wird, wenn die Foo2 Instanz versucht zugewiesen foo1 Referenz, die die reifiable Typ Foo1.

Sind Sie wahrscheinlich denken, "Okay, so explodierte es an der call-site, anstatt die Methode, große Sache." Aber es kann leicht komplizierter, wenn mehr Generika beteiligt sind. Zum Beispiel:

static <T extends Foo> List<T> getFooList(int size) {
    List<T> fooList = new ArrayList<T>(size);
    for (int i = 0; i < size; i++) {
        T foo = getFoo();
        fooList.add(foo);
    }
    return fooList;
}

public static void main(String[] args) {

    List<Foo1> foo1List = getFooList(5);

    //a bunch of things happen

    //sometime later maybe, depending on state
    foo1List.get(0).foo1Method(); //ClassCastException is thrown here
}

Nun ist es nicht sprengen, auf die call-Seite. Es weht bis irgendwann später, wenn sich der Inhalt foo1List gewöhnen. Dies ist, wie heap Umweltverschmutzung wird immer schwerer zu Debuggen, da das exception-stacktrace nicht Sie das eigentliche problem.

Wird es sogar noch komplizierter, wenn der Anrufer im generischen Bereich selbst. Stellen Sie sich anstelle einer List<Foo1> bekommen wir List<T>, indem es in eine Map<K, List<T>> und wieder noch eine andere Methode. Sie erhalten die Idee, wie ich hoffe.

Wie @Paul Bellora erwähnt in seiner Antwort, der Typ aufgelöst werden, indem der Anrufer, da im wesentlichen wird es jetzt, was es ist Berufung. Ich möchte nur hinzufügen, um seine Antwort mit einem Anwendungsfall, in dem ich denke, dass die Verwendung der syntax von nutzen sein konnte.

Gibt es immer alternativen, vermeiden Sie die Verwendung solcher syntax. Ich kann mir nicht vorstellen an einem einzigen Beispiel, dass dies absolut notwendig ist. Aber ich kann mir einen Einsatz bei einer bestimmten situation, dass diese syntax verwendet werden könnte, günstig, obwohl ich nicht einmal es mir. Ich weiß, das ist nicht das beste Beispiel, aber es kann auf den Punkt kommen.

Fall

Kurzem arbeite ich in der Entwicklung einer Benutzeroberfläche. In dieser Anwendung verwende ich eine Bibliothek zur Verwaltung der GUI-Elemente. Zusätzlich zu den Funktionen der Bibliothek, erstellte ich eine benutzerdefinierte Schnittstelle, die eine Ansicht definiert, die in meiner Anwendung, die Eingänge für einen bestimmten Typ von Daten, sagen wir, Eingabe von Koordinaten. Das interface Aussehen würde:

public interface CoordinateView extends View
{
    Coordinate getCoordinate();
    //Maybe more stuff
} 

Ich mehrere Fenster über meine Anwendung, die diese Schnittstelle implementieren. Jetzt können wir sagen, dass aus irgendeinem Grund, die ich speichern möchten, die in einem Modell der letzten Koordinate vorgelegt, in der ein Fenster, und schließen Sie das Fenster nach rechts. Dazu kann ich anfügen eine Prozedur, um das Fenster button, der das Formular sendet, wird der handler wird ausgelöst, wenn der Benutzer das Fenster schließt. Ich konnte erreichen, dass, indem Sie einfach die handler anonym in jedem Fenster, wie:

public MyWindow extends Window implements CoordinateView, OtherInterface
{
    private Button submitButton;

    public MyWindow()
    {
        super();
        //Create all the elements

        submitButton.addClickHandler(
            new ClickHandler()
            {
                @Override
                onCLick(ClickEvent e)
                {
                    getModel().add(getCoordinate());
                    destroy();
                }
            });  
   }
}

Aber dieses design ist nicht wünschenswert, für mich, es ist nicht modular genug. Bedenkt, dass ich haben eine anständige Menge an windows mit diesem Verhalten ändern, könnte es auch ziemlich langweilig. Also ich eher Extrakt der anonymen Methode in einer Klasse, so dass es wäre leichter zu ändern und zu pflegen. Aber das problem ist, dass die destroy() Methode ist nicht definiert eine Schnittstelle, ist nur ein Teil der Fenster und die getCoordinate () - Methode definiert ist, die in der Schnittstelle definierte ich.

Nutzung

In diesem Fall könnte ich mehrere Grenzen, wie die folgenden:

public class MyController <T extends Window & CoordinateView> implements ClickHandler
{
    private T windowWithCoordinates;

    public MyController (T window)
    {
        windowWithCoordinates = window;
    }

    @Override
    onClick(ClickEvent e)
    {
        getModel().add(windowWithCoordinates.getCoordinate());
        windowWithCoordinate.destroy();
    }
}

Dann den code in das windows wird jetzt:

public MyWindow extends Window implements CoordinateView, OtherInterface
{
    private Button submitButton;

    public MyWindow()
    {
        super();
        //Create all the elements

        submitButton.addClickHandler(new MyController<MyWindow>(this));

    }
}

Beachten Sie, dass das Verhalten bleibt das selbe, der code ist nur ein zusammenhalt wie früher zu sein. Seine nur mehr modular, aber es nicht erforderlich, die Einführung einer zusätzlichen Schnittstelle, um in der Lage sein, zu extrahieren, es richtig zu stellen.

Alternative

Alternativ hätte ich definiert eine zusätzliche Schnittstelle erweitern CoordinateView und eine Methode definieren, um das Fenster zu schließen.

public interface CoordinateWindow extends CoordinateView
{
    void destroy();
}

Dass die Fenster implementieren diese spezifischer Oberfläche, anstatt unnötige Verwendung von generischen Parameter in der extrahierten controller:

public class MyController implements ClickHandler
{
    private CoordinateWindow windowWithCoordinates;

    public MyController (CoordinateWindow window)
    {
        windowWithCoordinates = window;
    }

    @Override
    onClick(ClickEvent e)
    {
        getModel().add(windowWithCoordinates.getCoordinate());
        windowWithCoordinate.destroy();
    }
}


public MyWindow extends Window implements CoordinateWindow
{
    private Button submitButton;

    public MyWindow()
    {
        super();
        //Create all the elements  
        submitButton.addClickHandler(new MyController(this));                  
    }

    @Override
    void destroy()
    {
        this.destroy();
    }
}

Dieser Ansatz für einige gesehen werden kann, wie viel sauberer als die Vorherige und noch mehr wiederverwendbar, da es nun Hinzugefügt werden könnten, um andere "windows" - außerhalb der angegebenen Hierarchie. Ich persönlich bevorzuge diesen Ansatz als gut. Jedoch, kann es in ein wenig mehr codieren, da ein neues interface definiert werden, nur um sich einen Zugang zu einer gewünschten Methode.

Im Abschluss, obwohl ich persönlich es nicht empfehlen, ich denke, mit generischen Typen mit mehreren Grenzen könnten helfen, Kupplung Definitionen, während die Verringerung der Menge an code.