Como faço para o método retornar tipo genérico?

Considere este exemplo (típico nos livros de POO):

Eu tenho uma Animalaula, onde cada um Animalpode ter muitos amigos.
E subclasses como Dog, etc Duck, Mouseque adicionam comportamento específico bark(), quack()etc.

Aqui está a Animalturma:

public class Animal {
    private Map<String,Animal> friends = new HashMap<>();

    public void addFriend(String name, Animal animal){
        friends.put(name,animal);
    }

    public Animal callFriend(String name){
        return friends.get(name);
    }
}

E aqui está um trecho de código com muita tipografia:

Mouse jerry = new Mouse();
jerry.addFriend("spike", new Dog());
jerry.addFriend("quacker", new Duck());

((Dog) jerry.callFriend("spike")).bark();
((Duck) jerry.callFriend("quacker")).quack();

Existe alguma maneira de usar genéricos para o tipo de retorno para me livrar da conversão de texto, para que eu possa dizer

jerry.callFriend("spike").bark();
jerry.callFriend("quacker").quack();

Aqui está um código inicial com o tipo de retorno transmitido ao método como um parâmetro que nunca é usado.

public<T extends Animal> T callFriend(String name, T unusedTypeObj){
    return (T)friends.get(name);        
}

Existe uma maneira de descobrir o tipo de retorno em tempo de execução sem o parâmetro extra usando instanceof? Ou pelo menos passando uma classe do tipo em vez de uma instância fictícia.
Entendo que os genéricos são para verificação de tipo em tempo de compilação, mas existe uma solução alternativa para isso?

Você pode definir callFrienddesta maneira:

public <T extends Animal> T callFriend(String name, Class<T> type) {
    return type.cast(friends.get(name));
}

Em seguida, chame-o assim:

jerry.callFriend("spike", Dog.class).bark();
jerry.callFriend("quacker", Duck.class).quack();

Este código tem o benefício de não gerar nenhum aviso do compilador. É claro que essa é apenas uma versão atualizada do elenco dos dias pré-genéricos e não adiciona nenhuma segurança adicional.

Não. O compilador não pode saber que tipo jerry.callFriend("spike")retornaria. Além disso, sua implementação apenas oculta a conversão no método sem nenhum tipo de segurança adicional. Considere isto:

jerry.addFriend("quaker", new Duck());
jerry.callFriend("quaker", /* unused */ new Dog()); // dies with illegal cast

Nesse caso específico, criar um talk()método abstrato e substituí-lo adequadamente nas subclasses ajudaria você muito melhor:

Mouse jerry = new Mouse();
jerry.addFriend("spike", new Dog());
jerry.addFriend("quacker", new Duck());

jerry.callFriend("spike").talk();
jerry.callFriend("quacker").talk();

Você poderia implementá-lo assim:

@SuppressWarnings("unchecked")
public <T extends Animal> T callFriend(String name) {
    return (T)friends.get(name);
}

(Sim, este é um código legal; consulte Java Generics: tipo genérico definido apenas como tipo de retorno .)

O tipo de retorno será deduzido do chamador. No entanto, observe a @SuppressWarningsanotação: que informa que esse código não é seguro . Você precisa verificar por conta própria ou poderá obter ClassCastExceptionsem tempo de execução.

Infelizmente, do jeito que você o está usando (sem atribuir o valor de retorno a uma variável temporária), a única maneira de fazer o compilador feliz é chamá-lo assim:

jerry.<Dog>callFriend("spike").bark();

Embora isso possa ser um pouco melhor do que o elenco, é melhor você dar à Animalclasse um talk()método abstrato , como disse David Schmitt.

Essa pergunta é muito semelhante ao item 29 do Java efetivo - "Considere contêineres heterogêneos com segurança de tipo". A resposta de Laz é a mais próxima da solução de Bloch. No entanto, tanto o put quanto o get devem usar o literal de classe por segurança. As assinaturas se tornariam:

public <T extends Animal> void addFriend(String name, Class<T> type, T animal);
public <T extends Animal> T callFriend(String name, Class<T> type);

Dentro dos dois métodos, você deve verificar se os parâmetros estão corretos. Consulte Java efetivo e javadoc de classe para obter mais informações.

Além disso, você pode solicitar ao método que retorne o valor em um determinado tipo dessa maneira

<T> T methodName(Class<T> var);

Mais exemplos aqui na documentação do Oracle Java

Aqui está a versão mais simples:

public <T> T callFriend(String name) {
    return (T) friends.get(name); //Casting to T not needed in this case but its a good practice to do
}

Código totalmente funcional:

    public class Test {
        public static class Animal {
            private Map<String,Animal> friends = new HashMap<>();

            public void addFriend(String name, Animal animal){
                friends.put(name,animal);
            }

            public <T> T callFriend(String name){
                return (T) friends.get(name);
            }
        }

        public static class Dog extends Animal {

            public void bark() {
                System.out.println("i am dog");
            }
        }

        public static class Duck extends Animal {

            public void quack() {
                System.out.println("i am duck");
            }
        }

        public static void main(String [] args) {
            Animal animals = new Animal();
            animals.addFriend("dog", new Dog());
            animals.addFriend("duck", new Duck());

            Dog dog = animals.callFriend("dog");
            dog.bark();

            Duck duck = animals.callFriend("duck");
            duck.quack();

        }
    }

Como você disse que aprovar uma aula seria bom, você poderia escrever o seguinte:

public <T extends Animal> T callFriend(String name, Class<T> clazz) {
   return (T) friends.get(name);
}

E então use-o assim:

jerry.callFriend("spike", Dog.class).bark();
jerry.callFriend("quacker", Duck.class).quack();

Não é perfeito, mas isso é praticamente o máximo possível com os genéricos Java. Existe uma maneira de implementar os Contentores Heterogêneos Typesafe (THC) usando Super Type Tokens , mas isso tem seus próprios problemas novamente.

Com base na mesma idéia que os Super Type Tokens, você pode criar um ID digitado para usar em vez de uma string:

public abstract class TypedID<T extends Animal> {
  public final Type type;
  public final String id;

  protected TypedID(String id) {
    this.id = id;
    Type superclass = getClass().getGenericSuperclass();
    if (superclass instanceof Class) {
      throw new RuntimeException("Missing type parameter.");
    }
    this.type = ((ParameterizedType) superclass).getActualTypeArguments()[0];
  }
}

Mas acho que isso pode anular o objetivo, já que agora você precisa criar novos objetos de identificação para cada string e segurá-los (ou reconstruí-los com as informações de tipo corretas).

Mouse jerry = new Mouse();
TypedID<Dog> spike = new TypedID<Dog>("spike") {};
TypedID<Duck> quacker = new TypedID<Duck>("quacker") {};

jerry.addFriend(spike, new Dog());
jerry.addFriend(quacker, new Duck());

Mas agora você pode usar a classe da maneira que queria originalmente, sem os elencos.

jerry.callFriend(spike).bark();
jerry.callFriend(quacker).quack();

Isso está apenas ocultando o parâmetro type dentro do id, embora isso signifique que você pode recuperar o tipo do identificador posteriormente, se desejar.

Você também precisará implementar os métodos de comparação e hash de TypedID, se quiser comparar duas instâncias idênticas de um ID.

"Existe uma maneira de descobrir o tipo de retorno em tempo de execução sem o parâmetro extra usando instanceof?"

Como uma solução alternativa, você pode utilizar o padrão Visitor assim. Tornar o Animal abstrato e implementá-lo Visível:

abstract public class Animal implements Visitable {
  private Map<String,Animal> friends = new HashMap<String,Animal>();

  public void addFriend(String name, Animal animal){
      friends.put(name,animal);
  }

  public Animal callFriend(String name){
      return friends.get(name);
  }
}

Visível significa apenas que uma implementação Animal está disposta a aceitar um visitante:

public interface Visitable {
    void accept(Visitor v);
}

E uma implementação de visitante pode visitar todas as subclasses de um animal:

public interface Visitor {
    void visit(Dog d);
    void visit(Duck d);
    void visit(Mouse m);
}

Então, por exemplo, uma implementação Dog seria assim:

public class Dog extends Animal {
    public void bark() {}

    @Override
    public void accept(Visitor v) { v.visit(this); }
}

O truque aqui é que, como o cão sabe que tipo é, ele pode acionar o método de visita sobrecarregado relevante do visitante v, passando "this" como parâmetro. Outras subclasses implementariam accept () exatamente da mesma maneira.

A classe que deseja chamar métodos específicos da subclasse deve implementar a interface do Visitante desta forma:

public class Example implements Visitor {

    public void main() {
        Mouse jerry = new Mouse();
        jerry.addFriend("spike", new Dog());
        jerry.addFriend("quacker", new Duck());

        // Used to be: ((Dog) jerry.callFriend("spike")).bark();
        jerry.callFriend("spike").accept(this);

        // Used to be: ((Duck) jerry.callFriend("quacker")).quack();
        jerry.callFriend("quacker").accept(this);
    }

    // This would fire on callFriend("spike").accept(this)
    @Override
    public void visit(Dog d) { d.bark(); }

    // This would fire on callFriend("quacker").accept(this)
    @Override
    public void visit(Duck d) { d.quack(); }

    @Override
    public void visit(Mouse m) { m.squeak(); }
}

Sei que são muito mais interfaces e métodos do que você esperava, mas é uma maneira padrão de lidar com cada subtipo específico com exatamente zero instância de verificações e zero tipos de conversão. E tudo é feito de uma maneira independente de linguagem padrão, portanto não é apenas para Java, mas qualquer linguagem OO deve funcionar da mesma maneira.

Não é possivel. Como o Mapa deve saber qual subclasse de Animal será obtida, considerando apenas uma chave String?

A única maneira de isso ser possível é se cada Animal aceitar apenas um tipo de amigo (então pode ser um parâmetro da classe Animal) ou o método callFriend () obter um parâmetro de tipo. Mas realmente parece que você está perdendo o ponto de herança: é que você só pode tratar subclasses de maneira uniforme ao usar exclusivamente os métodos da superclasse.

Escrevi um artigo que contém uma prova de conceito, classes de suporte e uma classe de teste que demonstra como os Super Type Tokens podem ser recuperados por suas classes em tempo de execução. Em poucas palavras, permite delegar a implementações alternativas, dependendo dos parâmetros genéricos reais passados ​​pelo chamador. Exemplo:

• TimeSeries<Double> delega a uma classe interna privada que usa double[]
• TimeSeries<OHLC> delega a uma classe interna privada que usa ArrayList<OHLC>

Consulte: Usando TypeTokens para recuperar parâmetros genéricos

obrigado

Richard Gomes - Blog

Há muitas ótimas respostas aqui, mas essa é a abordagem que eu adotei para um teste do Appium em que agir em um único elemento pode resultar em diferentes estados de aplicativos com base nas configurações do usuário. Embora não siga as convenções do exemplo do OP, espero que ajude alguém.

public <T extends MobilePage> T tapSignInButton(Class<T> type) throws NoSuchMethodException, IllegalAccessException, InvocationTargetException, InstantiationException {
    //signInButton.click();
    return type.getConstructor(AppiumDriver.class).newInstance(appiumDriver);
}

• MobilePage é a super classe que o tipo estende, o que significa que você pode usar qualquer um dos filhos (duh)
• type.getConstructor (Param.class, etc) permite que você interaja com o construtor do tipo. Esse construtor deve ser o mesmo entre todas as classes esperadas.
• newInstance usa uma variável declarada que você deseja passar para o novo construtor de objetos

Se você não deseja lançar os erros, pode pegá-los da seguinte maneira:

public <T extends MobilePage> T tapSignInButton(Class<T> type) {
    // signInButton.click();
    T returnValue = null;
    try {
       returnValue = type.getConstructor(AppiumDriver.class).newInstance(appiumDriver);
    } catch (Exception e) {
        e.printStackTrace();
    }
    return returnValue;
}

Na verdade, não, porque, como você diz, o compilador sabe apenas que callFriend () está retornando um Animal, não um Cachorro ou Pato.

Você não pode adicionar um método abstrato makeNoise () ao Animal que seria implementado como uma casca ou charlatão por suas subclasses?

O que você está procurando aqui é abstração. Código contra interfaces mais e você deve ter que fazer menos transmissões.

O exemplo abaixo está em C #, mas o conceito permanece o mesmo.

using System;
using System.Collections.Generic;
using System.Reflection;

namespace GenericsTest
{
class MainClass
{
    public static void Main (string[] args)
    {
        _HasFriends jerry = new Mouse();
        jerry.AddFriend("spike", new Dog());
        jerry.AddFriend("quacker", new Duck());

        jerry.CallFriend<_Animal>("spike").Speak();
        jerry.CallFriend<_Animal>("quacker").Speak();
    }
}

interface _HasFriends
{
    void AddFriend(string name, _Animal animal);

    T CallFriend<T>(string name) where T : _Animal;
}

interface _Animal
{
    void Speak();
}

abstract class AnimalBase : _Animal, _HasFriends
{
    private Dictionary<string, _Animal> friends = new Dictionary<string, _Animal>();


    public abstract void Speak();

    public void AddFriend(string name, _Animal animal)
    {
        friends.Add(name, animal);
    }   

    public T CallFriend<T>(string name) where T : _Animal
    {
        return (T) friends[name];
    }
}

class Mouse : AnimalBase
{
    public override void Speak() { Squeek(); }

    private void Squeek()
    {
        Console.WriteLine ("Squeek! Squeek!");
    }
}

class Dog : AnimalBase
{
    public override void Speak() { Bark(); }

    private void Bark()
    {
        Console.WriteLine ("Woof!");
    }
}

class Duck : AnimalBase
{
    public override void Speak() { Quack(); }

    private void Quack()
    {
        Console.WriteLine ("Quack! Quack!");
    }
}
}

Eu fiz o seguinte no meu kontraktor lib:

public class Actor<SELF extends Actor> {
    public SELF self() { return (SELF)_self; }
}

subclasse:

public class MyHttpAppSession extends Actor<MyHttpAppSession> {
   ...
}

pelo menos isso funciona dentro da classe atual e ao ter uma referência digitada forte. Herança múltipla funciona, mas fica realmente complicado :)

Eu sei que isso é uma coisa completamente diferente que a pergunta. Outra maneira de resolver isso seria a reflexão. Quero dizer, isso não tira o benefício da Generics, mas permite imitar, de alguma forma, o comportamento que você deseja executar (fazer um cachorro latir, fazer um pato grasnar, etc.) sem cuidar do tipo de conversão:

import java.lang.reflect.InvocationTargetException;
import java.util.HashMap;
import java.util.Map;

abstract class AnimalExample {
    private Map<String,Class<?>> friends = new HashMap<String,Class<?>>();
    private Map<String,Object> theFriends = new HashMap<String,Object>();

    public void addFriend(String name, Object friend){
        friends.put(name,friend.getClass());
        theFriends.put(name, friend);
    }

    public void makeMyFriendSpeak(String name){
        try {
            friends.get(name).getMethod("speak").invoke(theFriends.get(name));
        } catch (IllegalArgumentException e) {
            e.printStackTrace();
        } catch (SecurityException e) {
            e.printStackTrace();
        } catch (IllegalAccessException e) {
            e.printStackTrace();
        } catch (InvocationTargetException e) {
            e.printStackTrace();
        } catch (NoSuchMethodException e) {
            e.printStackTrace();
        }
    } 

    public abstract void speak ();
};

class Dog extends Animal {
    public void speak () {
        System.out.println("woof!");
    }
}

class Duck extends Animal {
    public void speak () {
        System.out.println("quack!");
    }
}

class Cat extends Animal {
    public void speak () {
        System.out.println("miauu!");
    }
}

public class AnimalExample {

    public static void main (String [] args) {

        Cat felix = new Cat ();
        felix.addFriend("Spike", new Dog());
        felix.addFriend("Donald", new Duck());
        felix.makeMyFriendSpeak("Spike");
        felix.makeMyFriendSpeak("Donald");

    }

}

A respeito

public class Animal {
private Map<String,<T extends Animal>> friends = new HashMap<String,<T extends Animal>>();

public <T extends Animal> void addFriend(String name, T animal){
    friends.put(name,animal);
}

public <T extends Animal> T callFriend(String name){
    return friends.get(name);
}

}

Há outra abordagem: você pode restringir o tipo de retorno ao substituir um método. Em cada subclasse, você teria que substituir o callFriend para retornar essa subclasse. O custo seria as várias declarações de callFriend, mas você poderia isolar as partes comuns em um método chamado internamente. Isso me parece muito mais simples do que as soluções mencionadas acima e não precisa de um argumento extra para determinar o tipo de retorno.

public <X,Y> X nextRow(Y cursor) {
    return (X) getRow(cursor);
}

private <T> Person getRow(T cursor) {
    Cursor c = (Cursor) cursor;
    Person s = null;
    if (!c.moveToNext()) {
        c.close();
    } else {
        String id = c.getString(c.getColumnIndex("id"));
        String name = c.getString(c.getColumnIndex("name"));
        s = new Person();
        s.setId(id);
        s.setName(name);
    }
    return s;
}

Você pode retornar qualquer tipo e receber diretamente como. Não precisa digitar.

Person p = nextRow(cursor); // cursor is real database cursor.

É melhor se você deseja personalizar qualquer outro tipo de registro em vez de cursores reais.