我有一个通用的功能接口(interface):

@FunctionalInterface
public interface Feeder<T extends Animal> {
  void feed(T t);
}

@Configuration
public class Config {
  @Bean
  public Feeder<Dog> dogFeeder() {
    return dog -> dogService.feedDog(dog);
  }
  @Bean
  public Feeder<Cat> catFeeder() {
    return cat -> catService.feedCat(cat);
  }
}

@Service
public class PetStore {
  @Autowired
  private List<Feeder<? extends Animal> feeders;

  private void feed(Animal animal) {
    //TODO: How to determine the correct feeder from feeders?
    Feeder<? extends Animal> correctFeeder = ....
    correctFeeder.feed(animal);
  }
}

最佳答案

简短答案

恐怕没有真正干净的方法。由于类型被删除，因此您需要将类型信息保留在某处，并且使用getAnimalClass()的第三个建议是做到这一点的一种方法(但是，您尚不清楚如何将其稍后使用)。

我个人将摆脱lambda，并在canFeed(animal)中添加Feeder来委托(delegate)决策(而不是添加getAnimalClass())。这样，Feeder负责了解它可以喂食哪些动物。

因此，类型信息将保留在Feeder类中，例如，使用随构造传递的Class实例(或像您推测的那样覆盖getAnimalClass()):

final Class<T> typeParameterClass;

public Feeder(Class<T> typeParameterClass){
    typeParameterClass = typeParameterClass;
}

public boolean canFeed(Animal animal) {
   return typeParameterClass.isAssignableFrom(animal.getClass());
}

private Feeder feederFor(Animal animal) {
    return feeders.stream()
                  .filter(feeder -> feeder.canFeed(animal))
                  .findFirst()
                  .orElse((Feeder) unknownAnimal -> {});
}

@Autowired
Map<String, Feeder<? extends Animal>> feederMap;

private boolean canFeed(String feederName, Animal animal) {
    return feederName.contains(animal.getClass().getTypeName());
}

private Feeder feederFor(Animal animal) {
    return feederMap.entrySet().stream()
                    .filter(entry -> canFeed(entry.getKey(), animal))
                    .map(Map.Entry::getValue)
                    .findFirst()
                    .orElse((Feeder) unknownAnimal -> {});
}

default <A extends Animal> boolean canFeed(A animalToFeed) {
    return A == T;
}

this.entityBeanType = ((Class) ((ParameterizedType) getClass()
    .getGenericSuperclass()).getActualTypeArguments()[0]);

Before throwing this use case under the bus, we did some corpus analysis to found how often abstract class SAMs are used compared to interface SAMs. We found that in that corpus, only 3% of the lambda candidate inner class instances had abstract classes as their target. And most of them were amenable to simple refactorings where you added a constructor/factory that accepted a lambda that was interface-targeted.

default <A extends Animal> boolean canFeed(A animalToFeed) {
    Class<?> feederType = TypeResolver.resolveRawArgument(Feeder.class, this.getClass());
    return feederType.isAssignableFrom(animalToFeed.getClass());
}

@Autowired
private List<Feeder<? extends Animal>> feeders;

public void feed(Animal animal) {
    feederFor(animal).feed(animal);
}

private Feeder feederFor(Animal animal) {
    return feeders.stream()
                  .filter(feeder -> feeder.canFeed(animal))
                  .findFirst()
                  .orElse(unknownAnimal -> {});
}

关于java - 如何确定使用lambda实现泛型FunctionalInterface的Bean的类型参数？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/43937793/