Nous avons l'habitude de
class ClassTypeA implements InterfaceTypeA {}
class ClassTypeB extends ClassTypeA {}
et toute légère déviation de ces règles nous déroute beaucoup.
La syntaxe d'une limite de type est définie comme
TypeBound:
extends TypeVariable
extends ClassOrInterfaceType {AdditionalBound}
( JLS 12> 4.4. Variables de type>TypeBound
)
Si nous devions le changer, nous ajouterions sûrement le implements
cas
TypeBound:
extends TypeVariable
extends ClassType {AdditionalBound}
implements InterfaceType {AdditionalBound}
et se retrouver avec deux clauses traitées de manière identique
ClassOrInterfaceType:
ClassType
InterfaceType
( JLS 12> 4.3. Types et valeurs de référence>ClassOrInterfaceType
)
sauf qu'il faudrait aussi s'en occuper implements
, ce qui compliquerait encore les choses.
Je crois que c'est la principale raison pour laquelle extends ClassOrInterfaceType
on utilise au lieu de extends ClassType
et implements InterfaceType
- pour garder les choses simples dans le concept compliqué. Le problème est que nous n'avons pas le mot juste pour couvrir à la fois extends
et implements
nous ne voulons certainement pas introduire un.
<T is ClassTypeA>
<T is InterfaceTypeA>
Bien qu'il extends
apporte un peu de désordre lorsqu'il accompagne une interface, c'est un terme plus large et il peut être utilisé pour décrire les deux cas. Essayez de régler votre esprit sur le concept d' extension d'un type (pas d' extension d'une classe , pas d' implémentation d'une interface ). Vous limitez un paramètre de type par un autre type et peu importe ce que ce type est réellement. Il importe seulement que ce soit sa limite supérieure et son super-type .
implements
?" - "Parce qu'il n'y a queextends
".