2010-03-12 4 views
2

En Java, je me demande pourquoi l'attribut "length" de la classe String n'est pas privé? N'est-ce pas une mauvaise pratique selon le principe d'encapsulation? Pourquoi n'y a-t-il pas de méthode comme "getLength()" par exemple?Pourquoi l'attribut "longueur" est-il public dans la classe String?

PS: Désolé pour mon anglais, je l'améliore encore.

+0

'String.length()' est une méthode, n'est-ce pas? http://java.sun.com/j2se/1.4.2/docs/api/java/lang/String.html#length() –

+2

Vouliez-vous demander à propos de 'longueur' sur un tableau? Si oui, voir ici: http://stackoverflow.com/questions/1965500/length-and-length-in-java –

+0

Vous avez raison Jørn Schou-Rode! Je suis confus avec la longueur d'un tableau. Désolé pour cette erreur =/ – lost3den

Répondre

8

En fait, c'est vraiment privé. Peut-être que votre confusion avec la méthode length()?

+0

Il est tout à fait raisonnable d'avoir une implémentation 'String' sans champ' length' ou 'length'. On peut dire qu'une meilleure implémentation de 'String' (particulièrement maintenant que' StringBuffer' est moins utilisé et a changé d'implémentation) consiste à utiliser un 'char []' exactement de la bonne longueur - pas de champs 'length' ou' offset' nécessaires. –

4

Il n'y a pas d'attribut public appelé "length" dans java.lang.String. Il existe une méthode publique "length()", mais vous ne pouvez pas l'utiliser pour définir la longueur de la chaîne. Il est discutable qu'ils auraient dû appeler la méthode length() getLength(), mais c'était juste un choix qu'ils ont fait.

+0

Ou taille(), puisque la méthode de taille est définie pour toutes les collections ... – Riduidel

+0

J'ai toujours supposé que la méthode 'longueur()' était nommée de façon à avoir le même nom que le tableau ' propriété de longueur. – Powerlord

+0

Je pense que length() a été créé (au lieu de getLength) avant que la spécification Java Bean ait été créée. –

0

Avertissement:sujet Tangentielle

attributs publics ne sont pas intrinsèquement mauvais. Le problème avec Java est qu'il n'a pas properties, ce qui vous permet d'avoir des variables internes exposées au début. Lorsque vos exigences pour l'encapsulation deviennent plus fortes, vous pouvez changer les internes de la classe sans affecter sa signature/API. Avec les propriétés, vous pouvez avoir votre gâteau et le manger aussi, vous pouvez accéder à une propriété en tant que variable, mais étant incapable de définir/assigner à l'extérieur de la classe.

Les programmeurs Java contourner cela en créant dès le début des getters et des setters pour chaque attribut public face, qu'il ait ou non un traitement, juste au cas. J'ai vu des programmeurs Java démarrer sur d'autres langages que ont des propriétés faisant le même péché d'utiliser getters et setters chose. S'il vous plaît, si vous allez un jour dans une autre langue, ne rapportez pas toutes les idées fausses de Java issues des détails d'implémentation de la JVM. Encapsulation! = Getters & & Setter.

</rant>

+0

La chaîne est une classe immuable, et exposer sa longueur pour la modification serait un péché majeur. – DJClayworth

+1

voyager ne suggère pas qu'il soit exposé pour modification. de plus, il semble que "je souhaite que Java soit plus proche de C#/Scala/other-languages-with-properties". Bien sûr, c'est toujours une réponse complètement hors sujet. – Carl

+1

@voyager Les classes Java ont très certainement des propriétés. La spécification JavaBeans formalise ce que signifie être une propriété en Java. Il se trouve que le langage implique leur manifestation publique comme un ensemble d'accesseurs et de mutateurs conformes à une certaine convention de nommage. Les attributs publics ne sont en effet pas intrinsèquement mauvais, et vous n'avez pas besoin de sortir de Java pour voir que: les classes peuvent avoir des propriétés publiques en lecture seule. Les champs * modifiables publics sont intrinsèquement mauvais. Ils exposent l'état de l'objet d'une manière incontrôlée. –

0

Je pense que vous voulez dire les objets du tableau, à droite?

Personnellement, je pense qu'il est tout à fait correct d'avoir des champs (de préférence finaux) sur des classes qui ne sont que des structures glorifiées. Par exemple, je préfère faire

public Person { 
    final String name; 
    final String surname; 

    public Person(String name, String surname) { 
    this.name = name; 
    this.surname = surname; 
    } 
} 

que la même chose avec les getters et les setters.

+0

Les champs publics ne sont jamais une bonne idée! Si vous voulez des constantes publiques, utilisez enums. Les champs publics excluent la possibilité d'ajouter des fonctionnalités dans un refactoring ultérieur. Vous pourriez penser que votre objet est si simple et parfait qu'il ne changera jamais, mais ce n'est pas une bonne décision lorsque l'alternative, g/setters, est une solution si simple (et automatique avec les IDE d'aujourd'hui). En outre, il est si courant de s'attendre à ce que les g/setters de nos jours, si quelqu'un utilisait votre "structure glorifiée", ils le considéreraient probablement comme inhabituel. – nicerobot

+0

Exactement raison, c'est pourquoi je ne fais cela que sur des petites classes avec des champs privés-paquet. Tout ce qui montre des signes de germination des jambes, je reviens immédiatement à l'aide de getters. – lindelof

+0

@nicerobot "Les champs publics ne sont jamais une bonne idée!". Java a pensé que c'était une bonne idée quand ils ont créé la propriété .length dans les tableaux. Les tableaux ne changent pas comme les chaînes ne le font pas. –

Questions connexes