Y a-t-il une raison pour laquelle un tableau en Java est un objet? P>
6 Réponses :
afin qu'ils obtiennent toutes ses avantages: p>
etc. p>
et les tableaux ne sont pas «primitifs», donc s'ils ne peuvent pas être primitifs, ils doivent être des objets. P>
En Java, les implémentations CODE> HASHCODE CODE> et TOSTRING CODE> sont utilisées (nommément, code de hachage d'identité et [LFOOBAR; @deadbeef code>) pour les tableaux, donc Ils ne sont pas vraiment très utiles en général. :-P
Je ne suis pas sûr de la raison officielle. P>
Cependant, cela a du sens pour moi qu'ils sont des objets car les opérations peuvent être effectuées sur elles (telles que prendre la longueur) et avoir plus logique de prendre en compte ces opérations en tant que fonctions membres plutôt que d'introduire de nouveaux mots-clés. Les autres opérations comprennent le clone (), les opérations héritées d'objet, etc. Les tableaux sont également hachables et potentiellement comparables. p>
Ceci est différent des tableaux C (et natifs en C ++), où vos tableaux sont essentiellement des pointeurs vers un décalage de mémoire. p>
En fait, prendre la longueur d'un tableau Java n'est pas une opération. La longueur est un membre public de l'objet.
C'est vrai. Je ne suis pas sûr de savoir pourquoi ils n'ont pas mis dans une gamme finale () sur eux.
Les tableaux ne sont pas comparables à l'aide d'un ordre naturel, mais vous êtes bien sûr libre d'écrire un comparateur code> qui fonctionne avec eux.
@Chris: Bien sûr. Mais Careto prend un objet, donc tout ce que vous comparez (y compris les tableaux) doit être un objet.
Avoir des matrices Soyez des objets signifie que vous pouvez effectuer des opérations avec eux (par exemple, SOMARRAY.COUNT ('FOO')) au lieu de le faire contre eux (par exemple, compte (SOMARRAY, 'FOO')), ce qui conduit à Syntaxe plus naturelle. P>
Sauf en Java, les tableaux n'ont pas de méthodes supplémentaires, sauf Clone CODE> (qui a le type de retour de covariant correct, est public et n'a aucune exception vérifiée). Ils ont également un champ supplémentaire, longueur code>. Au-delà de cela, pas de méthodes supplémentaires ou de champs au-delà de ce qui est fourni avec objet code> sont disponibles.
Un autre point est que les objets sont mutables et transmis par référence. Dans les matrices, il n'y a pas de champs / méthodes que vous pouvez utiliser pour modifier les "propriétés" du tableau, mais vous pouvez certainement muter les valeurs d'élément. Et les avantages des tableaux de passage par référence sont assez évidents (bien que les programmeurs fonctionnels souhaitent probablement que Java avait des listes immuables adoptées par la valeur). p>
EDIT: oublié de mentionner. Au cours de la période précédant AutoBoxing, il a été utile de pouvoir stocker des tableaux dans des collections, écrivez-les à des objectifs, etc. P>
Je voulais +1 vous pour le passage par référence, mais pourquoi quelqu'un voudrait-il passer une chose immuable par valeur? Un grand + avec immuabilité est que vous pouvez passer par référence sans crainte des effets secondaires.
Passage par valeur ne signifie pas nécessairement la copie de la valeur. En fait, dans les langues avec transparence référentielle: en.wikipedia.org/wiki/... La distinction n'est pas pertinente.
Probablement parce qu'ils voulaient être aussi proches que possible de tout faire un objet. Les types indigènes sont là pour la compatibilité arriérée. P>
Parce que la spécification de langue java dit SO : ) p>
Dans les tableaux de langue de programmation Java sont des objets (§4.3.1), sont créés de manière dynamique et peuvent être attribués à des variables d'objet de type (§4.3.2). Toutes les méthodes d'objet de classe peuvent être invoquées sur un tableau. P> blockQuote>
Donc, Contrairement à C ++, Java fournit de véritables récits comme des objets de première classe: P>
- Il y a un membre
membre code>. li>- Il y a une méthode
clone () code> qui remplace la méthode du même nom dans la classeobjet code>. li>- plus tous les membres de la classe
objet code>. li>- Une exception est lancée si vous essayez d'accéder à un tableau hors limites. LI>
- Les matrices sont instanciées dans la mémoire dynamique. LI> ul>
Eh bien, les tableaux ne sont certainement pas primitifs.
De quel fond venez-vous? C?