После выполнения некоторого чтения, кажется, что можно использовать оператор & требует многократного распространяется: Class<T extends Class1 & Class2> classObj;
Java: не оператор подстановки ограничивающей
Однако я искал способ для обеспечения «не» функциональность во время компиляции. У меня есть пример, где Банан расширяет Фрукты. Тем не менее, я после того, как что-то вдоль линий:
public abstract class Fruit
{
public abstract String getFlavour();
}
public class Lemon extends Fruit
{
@Override
public String getFlavour()
{
return "sour";
}
}
public abstract class Banana extends Fruit
{
@Override
public String getFlavour()
{
return "very sweet!";
}
public abstract String getBananaRipeness();
}
public class UnripeBanana extends Banana
{
@Override
public String getBananaRipeness()
{
return "unripe";
}
}
...
public String methodThatTakesFruitClassButNotBanana(Class<? extends Fruit ! Banana> fruitClass)
{
Fruit fruit = fruitClass.newInstance();
return fruit.getFlavour();
}
...
methodThatTakesFruitClassButNotBanana(Lemon.class); // I want this to compile.
methodThatTakesFruitClassButNotBanana(UnripeBanana.class); // I want this not to compile.
Очевидно Class<? extends Fruit ! Banana>
не является допустимым синтаксисом. Какие подходы вы могли бы рекомендовать для обеспечения такого типа иерархии типов во время компиляции?
Я не думаю, что есть простой способ сделать это - легче было бы сделать исключение во время выполнения. Но я бы поставил под вопрос дизайн, прежде чем пытаться найти обходное решение. Если вы можете что-то сделать с фруктами, которые нельзя сделать с бананом, то либо ваш банан не является плодом, либо, скорее всего, вы добавили слишком много материала в Фрукты, который не применим ни к каким фруктам. – assylias
@assylias -> вы ударили ноготь по голове. Банан действительно есть Фрукты, но в нашем дизайне это похоже на то, что он расширил еще один Фрукт - его нужно было наклеить выше в иерархии, а не там, где он есть. – studro