Tableau Java vs Tableau Scala
Semble qu'une différence entre le tableau Java et le tableau Scala est que le tableau Java est une variante co. Le tableau Scala ne l'est pas. Les deux sont mutables. En java, la méthode de tri peut prendre différents tableaux, tels que des tableaux de chaîne ou Int. Ceci est souvent cité comme un bon exemple du principe de substitution de Liskov. Semble un bon design pour moi? Dans Scala, nous savons que le tableau n'est pas une variante co. Bien que le tableau Scala soit conçu plus tard que Java. Je ne vois pas comment le tableau Scala est meilleur dans l'aspect de la co-variance. Il a peut être générique ceci est mieux que Java.
1 answers
Lorsque vous regardez plus loin, vous constaterez que les pères du langage Java ont décidé plus tard de rendre les génériques et non covariants. Et c'est pour de bonnes raisons.
, Car un List<Apple> n'est pas List<Fruit>. Sinon, vous pourriez faire des choses comme
List<Apple> apples = new ArrayList<>();
List<Fruit> fruits = apples;
fruits.add(new Banana());
Mais ne vous attendez pas à ça
Apple badApple = apples.get(0);
Est-ce un appel sûr? Si vous autorisez la covariance ici, ce n'est pas le cas!
Et surprise: c'est le problème des tableaux Java!
C'est donc vraiment un problème que les tableaux Java sont covariants! Et il est préférable que les tableaux Scala vous permettent de contrôler exactement leur "variance". En Scala, vous avez un contrôle total sur la variance; alors qu'en Java, ils sont toujours covariants.
Avoir des tableaux covariants était considéré comme un moyen pragmatique de permettre des méthodes "génériques" comme sort(Object[] objects) bien avant que quiconque ne pense avoir des génériques en Java. C'est près de 20 ans dans le passé. La manière" moderne " est, comme vous pouvez le voir: faire des choses différemment.
Le "coût" de cette décision est le fait que Java connaît également ArrayStoreException . Ce ne serait pas nécessaire, si les tableaux Java ne seraient pas covariants!